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run-time  situation   correctly , and  in  fact  most  of  the  graph  paths 
are  not  feasible,  i.e.  do  not  represent  possible  executions  of  the 
program.   However,  this  model  is  widely  adopted  for  two  main 
reasons:  (a)  Its  relatively  simple  structure  enables  us  to  develop 
a  comprehensive  analytic  theory,  to  construct  simple  algorithms 
which  perform  the  required  program  analysis  and  to  investigate 
general  properties  of  these  algorithms  in  detail  (cf.  [HE],  [AU] 
for  recent  surveys  of  the  subject) .   (b)  Isolation  of  feasible 
paths  from  non-feasible  ones  is  known  to  be  an  undecidable  problem, 
closely  related  to  the  Turing  machine  halting  problem. 

This  classical  technique  faces  significant  problems  in  the 
presence  of  procedures.   These  problems  reflect  the  dependence  of 
individual  inter-procedural  branches  upon  each  other  during  program 
execution,  a  dependence  which  is  known  at  compile  time  and  is 
essentially  independent  of  any  computation  performed  during  that 
execution.   Interprocedural  branching  is  thus  much  easier  to 
analyze  than  intra-procedural  branches,  which  usually  depend  on 
the  values  assumed  by  various  program  variables.   It  is  therefore 
very  tempting  to  exploit  our  special  knowledge  of  this  branching 
pattern  in  program  analysis,  thereby  tracing  the  program  flow  in 
a  more  accurate  manner. 

Interprocedural  flow  cannot  be  treated  as  a  simple  extension 
of  the  intra-procedural  flow,  but  calls  for  a  more  complicated 
model  whose  mathematical  properties  require  special  analysis.   In 
addition,  many  programming  languages  include  features  such  as 
procedure  variables,  and  parameter  transfer  by  reference  or  by 
name  (cf.  [AU])  which  complicate  the  analysis  of  inter-procedural 
flow. 
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It  is  therefore  not  surprising  that  inter-procedural  analysis 
has  been  neglected  in  much  research  on  data-flow  analysis.   Most 
of  the  recent  literature  on  this  subject  virtually  ignores  any 
inter-procedural  aspect  of  the  analysis,  or  splits  the  inter- 
procedural  analysis  into  a  preliminary  analysis  phase  which  gathers 
over-estimated  information  about  the  properties  of  each  procedure 
in  a  program  and  which  is  followed  by  an  intra-procedural  analysis 
of  each  procedure,  suppressing  any  inter-procedural  transfer  of 
control  and  using  instead  the  previously  collected,  over-estimated 
information  to  deduce  the  effects  of  procedure  calls  on  the  program 
behavior  (cf.  [AL2]).   These  approaches  use  a  relatively  simple 
model  of  the  program  at  the  expense  of  some  information  loss, 
arguing  that  such  a  loss  in  intrinsic  anyway  even  in  a  purely 
intra-procedural  model. 

However,  there  is  a  growing  feeling  among  researchers  that 
more  importance  should  be  given  to  inter-procedural  analysis, 
especially  in  deeper  analyses  with  more  ambitious  goals,  where 
avoidance  of  flow  over-estimation  is  likely  to  be  significant  in 
improving  the  results  of  the  analysis.   This  is  true  in  particular 
for  analyses  related  to  program  verification,  in  which  area 
several  recent  papers,  notably  [DM],  [GR] ,  [HA],  [GA]  and  [CO] 
have  already  addressed  this  issue.   We  may  also  mention  several 
recent  works  by  Rosen  [RO ]  ,  Barth  [BA]  and  Lomet  [LO] ,  which 
outline  some  inter-procedural  approaches  to  global  data-flow 
analysis. 

In  this  paper  we  introduce  two  new  techniques  for  performing 
inter-procedural  analysis  of  a  program  as  an  integral  part  of  its 
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global  flow  analysis.   These  two  approaches  use  two  somewhat 
different  graph  models  for  the  program  being  analyzed.   The  first 
approach,  which  we  term  the  functional  approach  views  procedures 
as  collections  of  structured  program  blocks,  and  aims  to  establish 
input-output  relations  for  each  such  block.   One  then  interprets 
procedure  calls  as  "super  operations"  whose  effect  on  the  program 
status  can  be  computed  using  those  relations.   This  approach 
relates  rather  closely  to  most  of  the  known  techniques  dealing  with 
interprocedural  flow,  such  as  the  "worst-case  assumptions,"  mixed 
with  processing  of  procedures  in  "inverse  invocation  order"  [AL2] 
Rosen's  "indirect  arcs"  method  [RO] ,  in-line  expansion  of  pro- 
cedures [AL3] ,  as  well  as  most  of  the  known  interprocedural  tech- 
niques for  program  verification  ( [GR] ,  [GA] ,  [HA]  and  [CO]).   Our 
version  of  this  first  technique  has  the  advantage  of  being  rather 
simple  to  define  and  implement  (admitting  very  efficient  implementa- 
tions for  several  important  special  cases) ,  and  is  valid  even  in 
the  presence  of  recursion.   The  above  mentioned  previous  approaches 
to  this  situation  are  either  much  more  complicated,  or  yield  only 
approximate  solutions. 

Ovir  second  technique ,  which  we  term  the  call-strings  approach 
is  somewhat  orthogonal  to  the  first  approach.   This  second  technique 
blends  inter-procedural  flow  analysis  with  the  analysis  of  intra- 
procedural  flow,  and  in  effect  turns  a  whole  program  into  a  single 
flow-graph.   However,  as  information  is  propagated  along  this  graph, 
it  is  "tagged"  with  an  encoded  history  of  the  procedure  calls 
encountered  during  propagation.   In  this  way  we  make  inter- 
procedural flow  explicit,  and  this  enables  us  to  determine,  when- 
ever we  encounter  a  procedure  return,  what  part  of  the  information 
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at  hand  can  validly  be  propagated  through  this  return,  and  what 
part  has  a  conflicting  call  history,  that  bars  such  propagation. 

Surprisingly  enough,  very  few  techniques  using  this  kind  of 
logic  have  been  suggested  up  to  now.   We  may  note  in  this  connec- 
tion that  a  crude  approach,  but  one  using  similar  logic,  would  be 
an  approach  in  which  procedure  calls  and  returns  are  interpreted  as 
ordinary  branch  instructions.  Even  though  the  possibility  of  such  an 
approach  has  been  suggested  occasionally  in  the  literature,  it  has 
never  been  considered  seriously  as  an  alternative  inter-procedural 
analysis  method.  A  related  approach  to  program  verification  has  been 
investigated  by  De-Bakker  and  Meertens  [DM] ,  but,  again,  this  has 
been  quite  an  isolated  attempt,  and  one  having  rather  discouraging 
results,  which  we  believe  to  be  due  mainly  to  the  ambitious  nature 
of  the  analyses  considered. 

We  shall  show  that  an  appropriate  sophistiaction  of  this 
approach  is  in  fact  quite  adequate  for  data-flow  analysis,  and  gives 
results  quite  comparable  with  those  of  the  functional  approach. 
This  latter  approach  also  has  the  merit  that  it  can  easily  be 
transformed  into  an  approximative  approach,  in  which  some  details 
of  interprocedural  flow  are  lost,  but  in  which  the  relevant  al- 
gorithms become  much  less  expensive. 

A  problem  faced  by  any  inter-procedural  analysis  is  the 
possible  presence  of  recursive  procedures.   The  presence  of  such 
procedures  causes  inter-procedural  flow  to  become  much  more  com- 
plex than  it  is  in  the  non-recursive  case,  mainly  because  the 
length  of  a  sequence  of  nested  calls  can  be  arbitrarily  large. 
Concerning  our  approaches  in  this  case,  we  will  show  that  they 
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always  converge  in  the  non-recursive  case,  but  may  fail  to  yield 
an  effective  solution  of  several  data-flow  problems  (such  as  con- 
stant propagation)  for  recursive  programs.   It  will  also  be  seen 
that  much  more  advanced  techniques  are  needed  if  we  are  to  cope 
fully  with  recursion  for  such  problems. 

We  note  that  it  is  always  possible  to  transform  a  program 
with  procedures  into  a  procedureless  program,  by  converting  pro- 
cedure calls  and  returns  into  ordinary  branch  instructions, 
monitored  by  an  explicit  stack.   If  we  do  this  and  simply  siibject 
the  resulting  program  to  intra-procedural  analysis,  then  we  are  in 
effect  ignoring  all  the  delicate  properties  of  the  inter- 
procedural  flow  and  thus  inevitably  over-estimating  flow.   This 
simple  observation  shows  that  the  attempt  to  perform  more  accurate 
inter-procedural  analysis  can  be  viewed  as  a  first  (and  relatively 
easy)  step  toward  accurate  analysis  of  more  sophisticated  pro- 
perties of  programs  than  are  caught  by  classical  global  analysis. 
This  paper  is  organized  as  follows:  Section  2  contains  pre- 
liminary notations  and  terminology.   Section  3  presents  the  func- 
tional approach,  first  in  abstract,  definitional  terms,  and  then 
shows  that  it  can  be  effectively  implemented  for  data-flow  prob- 
lems which  possess  a  finite  semilattice  of  possible  data  values, 
and  sketch  an  algorithm  for  that  purpose.   We  also  discuss  several 
cases  in  which  unusually  efficient  implementation  is  possible. 
(These  cases  include  many  of  those  considered  in  classical  data- 
flow analyses) .   Section  4  presents  the  call-strings  approach  in 
abstract,  definitional  terms  showing  that  it  also  yields  the 
solution  we  desire,  though  in  a  manner  which  is  not  necessarily 
effective  in  the  most  general  case.     in  Section  5  we  show  that 
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this  latter  approach  can  be  effectively  implemented  if  the  semi- 
lattice  of  relevant  data  values  is  finite,  and  investigate  some  of 
the  efficiency  parameters  of  such  an  implementation.   Section  6 
presents  a  variant  of  the  call  strings  approach  which  aims  at  a 
relatively  simple,  but  only  approximative,  implementation  of 
interprocedural  data-flow  analysis. 

We  would  like  to  express  our  gratitude  to  Jacob  T.  Schwartz 
for  encouragement  and  many  helpful  suggestions  and  comments  con- 
cerning this  research. 
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2 .   Notations  and  Terminology 

In  this  section  we  will  review  various  basic  notations  and 
terminology  used  in  intra-procedural  analysis,  which  will  be  re- 
ferred to,  and  modified,  subsequently.   The  literature  on  data- 
flow analysis  is  by  now  quite  extensive,  and  we  refer  the  reader 
to  [HE[  or  [AU] ,  two  excellent  recent  introductory  expositions  of 
that  subject. 

To  analyse  a  program  consisting  of  several  subprocedures ,  each 
subprocedure   p,   including  the  main  program,  is  first  divided 
into  basic  blocks.   An  (extended)  basic  block  is  a  maximal  single- 
entry  multi-exit  sequence  of  code.   For  convenience,  we  will  assume 
that  each  procedure  call  constitutes  a  single-instruction  block. 
We  also  assume  that  each  subprocedure  p  has  a  unique  exit  block, 
denoted  by  e  ,  which  is  also  assiimed  to  be  a  single-instruction 
block,  and  also  that  p  has  a  unique  entry  (root)  block,  denoted 

^y  ^p- 

Assume  for  the  moment  that  p  contains  no  procedure  calls. 
Then  the  flow-graph  G  of  p  is  a  rooted  directed  graph  whose  nodes 
are  the  basic  blocks  of  p,  whose  root  is  r  ,  and  which  contains 
an  edge  (m,n)  iff  there  is  a  direct  transfer  of  control  from  the 
basic  block  m  to  (the  start  of)  the  basic  block  n,  effected  by 
some  branch  instruction.   The  presence  of  calls  in  p  induces  sev- 
eral possible  inter-procedural  extensions  of  the  flow-graph, 
which  will  be  discussed  in  the  next  section. 
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Let  G  be  any  rooted  directed  graph.   G  is  denoted  by  a  triplet 
(N,E,r)  where  N  is  the  set  of  its  nodes,  E  the  set  of  edges  and 
r  its  root.   A  path  p  in  G  is  a  sequence  of  nodes  in  N 
(n, ^n-/ . . • /H,  )  such  that  for  each  1  £  j  <  k,  (n. ,n.  ,)  e  E.   p  is 
said  to  lead  from  n,  (its  initial  node)  to  n,  (its  terminal  node) . 
p  can  be  also  represented  as  the  corresponding  sequence  of  edges 
( (n, ,n2) / . . . , (n,  _, ,n,  ) ) .   The  length  of  p  is  defined  as  the  number 
of  edges  along  p  (k-1  in  the  above  notation) .   For  each  pair  of 
nodes  m,  n  e  N  we  define  path  (m,n)  as  the  set  of  all  paths  in  G, 
leading  from  m  to  n. 

We  assume  that  the  program  to  be  analyzed  is  written  in  a 
programming  language  with  the  following  semantic  properties: 
Procedure  parameters  are  transferred  by  value,  rather  than  by 
reference  or  by  name  (so  that  we  can,  and  will,  ignore  the  problem 
of  "aliasing"  discussed  by  Rosen  [RO] )  and  there  are  no  procedure 
variables  or  external  procedures.   We  also  assiime  that  the  program 
has  been  translated  into  an  intermediate-level  code  in  which  the 
transfer  of  values  between  actual  argtunents  and  formal  parameters 
of  a  procedure  is  explicit  in  the  code  and  is  accomplished  by 
argument-transmitting  assignments,  inserted  before  and  after  pro- 
cedure calls.   Because  of  this  last  assumption,  formal  parameters 
can  be  treated  in  the  same  way  as  other  global  variables.   All 
these  assumptions  are  made  in  order  to  simplify  our  treatment  and 
are  rather  reasonable.   If  the  first  two  assiimptions  are  not  sat- 
isfied then  things  get  much  more  complicated,  though  not  beyond 
control.   The  third  assumption  is  rather  arbitrary  but  most  con- 
venient.  (In  ICO],  e.g.,  the  converse  assumption  is  made,  namely 
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that  global  variables  are  passed  between  procedures  as  parameters, 
an  assumption  which  we  believe  to  be  less  favorable  technically.) 

A  global  data-flow  framework  is  defined  to  be  a  pair  (L,F) , 
where  L  is  a  semilattice  of  data-  or  attribute-information  and  F 
is  a  space  of  functions  acting  in  L  (and  describing  a  possible 
way  in  which  data  may  propagate  along  program  flow).   Let  A  denote 
the  semilattice  operation  of  L  (called  a  meet) ,  which  is  assumed 
to  be  idempotent,  associative  and  commutative.   We  assume  that  L 
contains  a  smallest  element,  denoted  by  0  (usually  signifying 
null  information   (see  below) .   F  is  assumed  to  be  closed  under 
functional  composition  and  meet,  to  contain  an  identity  map,  and 
to  be  monotone,  i.e.  to  be  such  that  for  each  f  e  F,  x,  y  e  L, 
X  <_  y  implies  f(x)  <_  f(y).   L  is  also  assumed  to  be  bounded,  i.e. 
not  to  contain  any  infinite  decreasing  sequence  of  distinct  ele- 
ments.  (L,F)  is  called  a  distributive  framework  if,  for  each 
f  e  F  and  x,  y  e  L,  f (x  a  y)  =  f (x)  A  f (y) . 

Given  a  global  data-flow  framework  (L,F)  and  a  flow  graph  G, 

we  associate  with  each  edge  (m,n)  of  G  a  propagation  function 

f /    X  e  F,  which  represents  the  change  of  relevant  data-attributes 

as  control  passes  from  the  start  of  m,  through  m,  to  the  start  of 

n.   (Recall  that  a  basic  block  may  have  more  than  one  exit,  so  that 

f ,_   .  must  depend  on  n  as  well  as  m. 
(ni,n) 

Once  the  set  S  =  {f,    . :  (m,n)  e  E}  is  given,  we  can  define 

\iu ,  n  ^ 

a  (graph-dependent)  space  F  of  propagation  functions  as  the 
smallest  set  of  functions  acting  in  L  which  contains  S  and  the 
identity  map,  and  which  is  closed  under  functional  compositions 
and  meets.   It  is  clear  that  this  F  is  monotone  iff  S  is  monotone. 
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and  that  F  is  distributive  iff  S  is  distributive. 

Once  F  is  defined,  we  can  formulate  the  following  general  set 
of  data-propagation  equations,  where,  for  each  n  e  N,  x  denotes 
the  data  available  at  the  start  of  n: 

x^  =  0 
(2.1) 

x_  = 


These  equations  describe  attribute  propagation  "locally," 
i.e.  they  show  the  relation  between  attributes  collected  at  adja- 
cent basic  blocks,  starting  with  null  information  at  the  program 
entry. 

The  solutions  of  these  equations  approximate  the  following 
abstractly  defined  function  known  as  the  meet  over  all  paths 
solution  to  an  optimisation  problem 

(2.2)        y„  =  A  ^f  (0) :  P  e  path„(r,n) }  ,  n  e  N  ; 
n         p  Kj 

here  we  define  f=f,        xof,         ,...of,      .  for 

p     (n,,_i^nj^)    (nj,.2^nj^_^)       (n^^n^) 

each  path  p  =  (n, ,n2 , . . . ,n,  ) .   If  p  is  null,  then  f   is  defined 

to  be  the  identity  map  on  L. 

Many  algorithms  which  solve  equations  (2.1)  are  known  by  now. 

These  algorithms  fall  into  two  main  categories:  (i)  iterative 

algorithms,  which  use  only  functional  applications  (cf.  [KI] , 

[HU] ,  [KU2] ,  [HE],  [TAl]).   (ii)  elimination  algorithms,  which 

also  use  functional  compositions  and  meets  (cf.  [CA] ,  [GW] ,  [TA2]) 

All  these  algorithms  yield  the  maximal  fixed  point  solution  to 

equations  (2.1),  which  does  coincide  with  the  solution  (2.2) 
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provided  that  the  data-flow  framework  in  question  is  distributive 
[KI] ,  but  which  may  fail  to  do  so  if  the  framework  is  only  mono- 
tone [KUl] .   However,  in  which  case,  even  in  this  latter  case  we 

still  have  x   <  y   for  all  n  e  N,  i.e.  obtain  an  under-estimated 
n  —  -*  n 

solution,  which  is  always  a  safe  one  (cf.  [HE]).   In  what  follows, 
we  will  assume  some  basic  knowledge  of  these  classical  optimisation 
algorithms. 
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3.   The  functional  approach  to  interprocedural  analysis 

In  this  section  we  present  our  first  approach  to  interpro- 
cedural analysis.   This  approach  treats  each  procedure  as  a  struc- 
ture of  blocks,  which  establishes  relations  between  attribute  data 
at  its  entry  and  related  data  at  any  of  its  nodes.  Using  these 
relations,  attribute  data  is  propagated  directly  through  each 
procedure  call. 

We  prepare  for  our  description  by  giving  some  definitions  and 
making  some  observations  concerning  the  inter-procedural  nature 
of  general  programs.   Let  us  first  introduce  the  notion  of  an 
interprocedural  flow  graph  of  a  computer  program  containing  sev- 
eral procedures.   We  can  consider  two  alternative  representations 
of  such  a  graph  G.   In  the  first  representation,  we  have  G  = 
U  {g  :  p   is  a  procedure  in  the  program},  where,  for  each  p, 

G  =  (N  ,E  ,r  ) ,  and  where  r   is  the  entry  block  of  p,  N   is  the 
p    ^  p'  p'  p' '  p  ^  ^    P 

set  of  all  basic  blocks  within  p,  and  E  =  E°  u  e   is  the  set  of 

Sr  C  ST 

edges  of  G  .   An  edge  (m,n)  e  E°  iff  there  can  be  a  direct  trans- 
'       P  P 

fer  of  control  from  m  to  n  (via  a  'go-to'  or  'if  statement, 

and  {m,n)  e  E   iff  m  is  a  call  block  and  n  is  the  block  immediately 
P 

following  that  call. 

Thus  this  representation,  which  is  the  one  to  be  used  ex- 
plicitly in  our  first  approach,  separates  the  flow  graphs  of 
individual  procedures  from  each  other. 

A  second  representation,  denoted  by  G*,  is  defined  as  follows: 

G*  =  (N*,E*,r,)  ,  where  N*  =  ^  N  ,  and  E*  =  E°  U  E"^,  where  E°  = 

u  E°  and  an  edge  (m.n)  e  E  iff  either  m  is  a  call  block  and  n  is 
P   P 
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the  entry  block  of  the  called  procedure  (in  which  case  (m,n)  is 
called  a  call  edge) ,  or  if  m  is  an  exit  block  of  some  procedure  p 
and  n  is  a  block  immediately  following  a  call  to  p  (in  which  case 
(m,n)  is  called  a  return  edge) .   The  call  edge  (m,r  )  and  a  return 
edge  (e  ,n)  are  said  to  correspond  to  each  other  if  p=q  and 
(m,n)  e  E  ,  for  some  procedure  s.   Here  r-,  is  the  entry  block  of 
the  main  program,  sometimes  also  denoted  as  ^j^jg^n*   Of  course,  not 
all  paths  through  G*  are  (even  statically)  feasible,  in  the  sense 
of  representing  potentially  valid  execution  paths,  since  the 
definition  of  G*  ignores  the  special  nature  of  procedure  calls  and 
returns.   For  each  n  e  N*  we  define  IVP(r-,,n)  as  the  set  of  all 
inter-procedurally  valid  paths  in  G*  which  lead  from  r,  to  n.   A 
path  g  e  pathg^(r,,n)  is  in  IVP(r,,n)  iff  the  sequence  of  all 

^1 
proper  in  the  following  recursive  sense: 

(i)   A  tuple  q-,  which  contains  no  return  edges  is  proper. 

(ii)  If  q,  contains  return  edges,  and  i  is  the  smallest  index  in 
q,  such  that  q-i  (i)  is  a  return  edge,  then  q,  is  proper  if 
i>l  and  q, (i-1)  is  a  call  edge  corresponding  to  the  return 
edge  q-,(i),  and  after  deleting  those  two  components  from  q,, 
the  remaining  tuple  is  also  proper. 

Remark ;   It  is  interesting  to  note  that  the  set  of  all  proper 

tuples  over  E  ,  as  well  as   u  iVP(r,,n),  can  be  generated  by  a 

n 
context-free  grammar  (but  not  by  a  regular  grammar) ,  in  contrast 

with  the  set  of  all  possible  paths  in  G* ,  which  is  regular. 

For  each  procedure  p  and  each  n  e  N  ,  we  also  define 

rVP  (r  ,n)  as  the  set  of  all  interprocedxirally  valid  paths  q  in 


edges  in  q  which  are  in  E  ,  which  we  will  write  as  q,  or  q 
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G*  from  r   to  n  such  that  each  procedure  call  in  q  is  completed 
by  a  subsequent  corresponding  return  edge  in  q.   More  precisely, 

1  is  complete, 
in  the  following  recursive  sense. 


a  path  q  e  path  ^ (r  ,n)  is  in  IVP  (r  ,n)  iff  q^  =  q 


E 


(i)   The  null  tuple  is  complete. 

(ii)  A  tuple  q,  is  complete  if  it  is  either  a  concatenation  of  two 
complete  subtuples,  or  else  it  starts  with  a  call  edge, 
terminates  with  the  corresponding  return  edge,  and  the  rest 
of  its  components  constitute  a  complete  subtuple. 
The  notions  introduced  above  appear  in  the  following  Path 

Decomposition  Lemma: 

Lemma  3.1;   Let  n  e  N*  and  q  e  IVP  (r, ,n) .   Then  there  exist  pro- 
cedures Pt  ,Pt,  .  .  .  ,p  •  ,  where  p,  is  the  main  program  and  p..  the  pro- 
cedure  containing  n,  and  calls  c,,...,c._,  such  that  for  each  i<j 
c-  is  in  p.  and  calls  P-,-i»  and  q  can  be  represented  as 

(3.1)       q  =  q3_||(c^,rp  )|Iq2l  I  •  •  •  I  Kcj^i^r^  )  |  (q^ 

where  for  each  i<j   q.  e  IVP^Cr   ,c.)  and  q.  e  IVP^(r   ,n) . 

-'   ^1       o   p^   1       ^j  o   Pj 

Conversely,  any  path  which  admits  such  a  decomposition  is  in 
IVP(r,,n).   Moreover,  this  decomposition  is  unique. 

Proof ;   Let  q*  =  q   -i  •   If  q*  is  empty,  then  q*  is  also  complete, 

E 
so  that  q  e  IVP  (r, ,n) ,  and  we  have  the  trivial  decomposition 

q=q  with  j=l  (n  must  belong  to  the  main  program  in  this  case) . 

Otherwise,  in  view  of  the  definition  of  a  proper  E  -tuple, 

and  by  making  repeated  deletions  of  adjacent  call  edges  and 

corresponding  return  edges,  we  can  reduce  q*  to  a  tuple  q**  which 
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is  either  a  null  tuple  or  a  non-empty  tuple  containing  only  call 
edges.   Let  j  =  length  of  q**  +  1.   If  j=l/  i.e.  if  q**  is  empty, 
it  is  readily  seen  that  q*  is  complete  and  that  n  belongs  to  the 
main  program,  and  we  have  again  the  trivial  decomposition  q=q. 

If  j  >  1,  let  c.  =  q** (i) (1) ,  i=l,...,j-l,  and  put  p,  =  main 
program,  P-,-,  =  the  procedure  called  from  c.,  i=l,...,j-l.   In  view 
of  the  way  in  which  q**  was  obtained  from  q,  it  follows  that  c.  is 

in  p.  for  each  i  <  j.   Let  m^=l  and  m.  be  the  original  index  of 

1  "^  o  1 

q**(i)  in  q,  i=l,...,j-l.   Then  we  have  the  decomposition  q  = 
qil  I  (Cj_,rp  )  I  Iq2.  .  .  I  I  (Cj_i'^p.)  I  kj  where  q^  =  q  {m^_^+l  :m^-l)  , 
1=1,..., j-1,  and  q.  =  q(m.  ^+1:).'     It  is  easily  verified  that 


^i 


,  is  complete  for  each  i<j ,  and  therefore  q.  e  IVP  (r   ,c.) 
gl       ^  -^'  ^1      o'  p^'  i' 


for  i<j  and  q.  e  IVP  (r   ,n) . 
■^      ^  j      o   p . 

The  proof  of  the  converse  assertion  is  simpler,  and  follows 
directly  from  the  definitions  of  IVP  and  IVP  . 

The  viniqueness  of  this  decomposition  is  also  easy  to  estab- 
lish, since  c^^ , .  .  .  ,c  .^^  are  precisely  all  the  calls  along  q  which 
are  net  subsequently  completed,  and  it  is  fairly  obvious  from  the 
definitions  that  these  calls  and  their  positions  in  q  are  unique, 
which  immediately  implies  the  uniqueness  of  the  whole  decomposition. 

Q.E.D. 

We  can  now  describe  our  'functional'  approach  to  interproce- 
dural  analysis.  Let  (L,F)  be  a  distributive  data-flow  framework 
for  G.   In  the  first  phase  of  the  functional  approach  we  take  F 

(*) 

footnote;   for  any  tuple  or  string  a,  a(i:j)  denotes  its  sub- 
part from  the  i-th  component  to  the  j-th  one,  inclusive;  a(i:) 
denotes  the  subpart  of  a  from  the  i-th  component  to  its  end. 
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as  the  direct  basis  for  our  analysis.   More  precisely,  for  each 
procedure  p  and  each  n  e  N^,  we  define  an  element  0^^   ^   e  F 
Which  describes  the  manner  in  which  attributes  in  L  I^e^propagated 
from  the  start  of  r^  to  the  start  of  n  along  paths  in  IVP^(r  ,n) . 
These  functions  must  satisfy  the  following  (non-linear)  sit   of 
equations,  whose  heuristic  meaning  should  be  self-explanatory: 
For  each  (m,n)  e  E°,  let  f ^^^^^  e  F  denote  the  associated  propa- 
gation  effect.   Then 

Mr  ,r  )  ^  id  f   for  each  procedure  p 
(3.2)  P'  p'      -^ 

(rp,n)     (m,n)eE   ^"^(m^n)  °  "^(r  ,ra)  ^  '   ^°^  each  n  e  N   -  {r  } 

■f  p  P     P 

where 


(m,n) 


^^(m,n)     if   (ni,n)  c  E° 


^^''q'^g)   ""^  ^""'""^  ^  ^P  ^""^   ""  ""^^^^  procedure  q 


This  set  of  equations  possesses  a  maximal  fixed  point  solution 
which  is  defined  as  follows:  Let  F  be  ordered  by  writing  g^  >  g^ 
for  g^,  g^  e  F  iff  g^ (x)  >  g^ (x)  for  all  x  c  L.   (We  will  assume 
that  L  contains  a  maximal  element  n   which  denotes  a  totally  unde- 
fined attribute,  and  that  F  contains  a  function  f^  which  maps 
each  X  e  L  into  ^,    so  that  f^  is  the  largest  element  in  F.) 
Start  by  putting 


o 

-p'-p' 


*(r^,r„)  ~  ^"^L'   f°^  ^^^^   procedure  p 


*° 


(r  n)   "  f«'    fo^  each  n  e  N  -  {r  } 

ir  XT  hr 
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and  then  apply  Equations  (3.2)  iteratively  in  a  round  robin  fashion 
to  obtain  new  approximations  to  the  <i>'s,       (This  can  be  done  using 
iterations  either  of  Gauss-Seidel  type  of  Jacobi ' s  type,  though  the 
former  is  a  better  approach.)   Let  <t>^,  denote  the  i-th  approx- 

imation computed  in  this  manner.   Since  4°     s    >    <t>'^,  .  for  all 

^(r  ,n)  -^(r  ,n)   "^  ^-^-^ 

p,  n,  it  follows  inductively  that  (j))      >  <t>]t^      ,    for  each  p,  n 
and  i  >_0 . 

A  problem  which  arises  here  is  that  F  need  not  in  general  be 

a  bounded  semilattice,  even  if  L  is  bounded.   If  L  is  finite  then 

F  must  be  finite  and  therefore  bounded,  but  if  L  is  not  finite,  F 

need  not  in  general  be  bounded. 

Nevertheless,  even  if  the  sequence  {(})^,     ,}.  „  is  infinite  for 

(r  ,n)  3>_0 

some  p,  n  we  still  can  define  its  limit,  denoted  by  o  ,     .  ,  as 

^(rp,n)  ' 

follows:   For  each  x  e  L,  the  sequence  {({>^     \(x)}.^-  is  decreas- 

l  i  ,  n ;     J  >y 

ing  in  L,  and  since  L  is  bounded,  it  must  be  finite,  and  we  define 
*/_   „s  (x)  as  its  limit.   (To  ensure  that  <i> ,  ,  c  F  we  must 

impose  another  condition  upon  F,  namely:  for  each  decreasing 
sequence  ^gj_^j_>o  of  functions  in  F,  the  limit  defined  as  above  is 
also  in  F.)   Thus,  the  above  process  defined  a  solution 
^*(r  ,n)^p,n  ^°  equations  (3.2)  though  not  necessarily  effectively. 
It  is  easy  to  check  that  the  limiting  functions  defined  by  the 
iterative  process  that  we  have  described  are  indeed  a  solution, 
and  that  in  fact  it  is  the  maximal  fixed  point  solution  of  (3.2). 

Having  obtained  this  solution,  we  can  use  it  to  compute  a 
solution  to  our  data-flow  problem.   For  each  basic  block  n  let 
x^  e  L  denote  the  information  available  at  the  start  of  n.   Then 
we  have  the  following  set  of  equations: 
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(a)   x^     =  0  e  L 

main 

(3.3)   (b)   for  each  procedure  p, 

x^  =  AH(2:   c)  (^r  ^'  *3  ^2  ^  procedure  and 
^         ^'  ^   c  is  a  call  to  p  in  q} 

(c)   ^n  ~  *^  fr   n)  ^^  ^  '      ^°^  each  procedure  p,  and 

P'     ""P    n  e  N   -  {r„} 

P     P 

These  equations  can  be  (effectively)  solved  by  a  standard  iterative 
algorithm,  which  yields  the  maximal  fixed  point  solution  of  (3.3). 

We  illustrate  the  above  procedure  for  solution  of  equations 
(3.2)  and  (3.3)  by  the  following  example,  in  which  we  suppose 
that  available  expressions  analysis  is  to  be  performed: 


Example  1 


mam  program 
read  a,  b; 
t  :=  a*b; 
call  p; 
t  :=  a*b; 
print  t ; 
stop; 
end; 


procedure  p 

if  a  =  0  then  return; 

else 

a  :=  a  -  1; 

call  p; 

t  :=  a*b; 
end  if ; 
retxirn; 
end; 


Our  interprocedural  analysis  will  show  that  a*b  is  available 
upon  exit  from  the  recursive  procedure  p,  so  that  its  second 
computation  in  the  main  program  is  redundant  and  can  therefore 
be  eliminated.   (Traditional  inter-procedural  methods  will  usually 
fail  to  detect  this  fact,  since  the  expression  a*b  is  killed  in  p.) 
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We  now  exhibit  the  details  of  the  iterative  solution  of  equa- 
tions (3.2)  and  (3.3)  for  this  above  program  P.   Our  first  solution 
step  transforms  P  into  the  following  interprocedural  flow  graph 
(where  solid  arrows  denote  intra-procedural  edges,  dotted  arrows 

denote  edges  in  u  e  ,  and  dashed  arrows  denote  interprocedural 

P   ^   1 
edges,  i.e.  edges  in  E  ) : 


n. 


read  a,b 
t  :=  a*b 


jvk_ 


call  p 


_iZ. 


t  :=  a*b 
print  t 


<-- 


stop 


--> 

/7 
/  . 

if  a=0  then 
a  :=  a-1 

t 

v/ 

\^ 

call  p 

r 

v> 

,f 

t  :=  a*b 

1 
1 
\ 

V 

^    'X 

/ 

V  ^  V 

return 

n- 


For  simplicity  we  will  only  show  that  part  of  the  analysis,  which 
pertains  directly  to  the  single  expression  a*b.   Assuming  this 
simplification  ,L  =  {0,1,1^},  where  1  indicates  that  a*b  is  available 
and  0  that  it  is  not,  and  each  f  e  F  can  be  denoted  by  a  pair 
(a,b)  ,  where  a  =  f(0),  b  =  f(l)  (recall  that  f(n)  =9.   always), 
so  that  e.g.  id  =  (0,1).   With  these  notations,  equations  (3,2) 
read 


(r3_,r^) 

(r2,r2) 
(r^,Cj_) 


(0,1) 
(0,1) 

(1,1)  o  'I' 


(r^,r^) 
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^ir2,^2^    -    *(r2,e2)°  *(r2,C2) 
4- 


{r2,e2)  =  1(0, Do  *(.,.)  ^AE  d.D  o  *(.  ] 


The  following  table  summarizes  the  iterative  solution  of  these 
equations : 


function   initial  value   after  1 

iteration 


2  iterations   3  iterations 


Mr,,r,: 

(0,1) 

(0,1) 

(0,1) 

*(r,,c,' 

(«,«) 

(1,1) 

(1,1) 

^   1 

(n,n) 

(n,j^) 

(1,1) 

*/^    ^ 

(",") 

(n,s) 

(1,1) 

(r^^e^ 

^^2'^2' 

(0,1) 

(0,1) 

(0,1) 

*(r2,C2 

)            («,«) 

(0,0) 

(0,0) 

\^2 '^2 

(n,n) 

(«,«) 

(0,0) 

^^2'®2 

)             (^,n) 

(0,1) 

(0,1) 

(0,1) 

(1,1) 
(1,1) 
(1,1) 

(0,1) 
(0,0) 
(0,0) 
(0,1) 


Thus,  the  first  stage  of  one  solution  stabilizes  after  3  itera- 
tions.  Next  we  solve  equations  (3.3),  which  read  as  follows: 


(a) 
(b) 


=  0 


*,r,,=,,'=<r,'A*,r,.=,,'==r,) 


=  (1,1) (x^  )/\  (0,0) (x^  ) 
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For  these  equations  we  see  after  two  iterations  that 

X   =  X   =0 
from  which,  using  (3.3)  (c) ,  we  obtain  the  complete  solution 

r^    r2    C2    n^  e^ 

^1     "l     ®1 

i.e.  a*b  is  available  at  the  start  of  n^ ,  which  is  what  we  wanted 
to  show. 

Next  we  shall  analyze  the  properties  of  the  solution  of 
equations  (3.2)  and  (3.3)  as  defined  above.   As  in  intra-procedural 
analysis  our  main  objective  is  to  show  that  this  solution  coincides 
with  the  meet  over  all  paths  solrtion  defined  (in  the  interproce- 
dural  case)  as  follows: 

(3.4)  ^l,^   =  /\{f  :q  e  IVP  (r     n)  }  e  F,  for  each  n  e  N* 


(3.5)   y^  =  '^n^*^^'  ^°^  ®^^^  n  e  N*  (this  is  the  meet  over  all  paths 

solution) . 

Lemma  3.2;   Let  n  e  N   for  some  procedure  p.   Then 

*(rp,n)  =  A^fq:  q  e  IVP^(rp,n)} 
Proof:   We  first  prove,  by  induction  on  i,  that  for  all  i>_0 

*^,n)  ^  A^fq:  q  e  IVP^(rp,n)} 

Indeed,  for  i=0,  if  n=rp  then  *°^  ^^  ^  =  id^  =  f   ,  where 

P'  P  *^o 

^^o  ^  ^^^o^^p'^p)  is  the  empty  path  from  r   to  r  ,  so  that 

P     P 

♦Up,rp)  t   A(f,=  q  e   IVP^(rp,rp)}.   if  n^r^  then  ♦°^^^„,  =  f„  >  f 
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for  all  f  e  F.   Thus  the  assertion  is  true  for  i=0. 

Suppose  that  it  is  true  for  some  i.   For  either  kind  of 
iterative  computation  of  the  functions  <^^        using  equations  (3.2) 
we  have 

>  /  ^or.   (h,    ,°   A{f  :  q  e  IVP^(r^,m)}) 
-  (m,n)GE     (m,n)       q         op 

for  each  procedure  p  and  n  c  N   -  {r  }.  (Note  here  that  if  n  =  r  , 
^^^^  *(r'  n)  =  *(r  .n)  =  ^%.n)    i   %--    ^   ^  ^^^o^^p'^^^'   °^^ 

Cr  IT  IT 

chain  of  equalities  and  inequalities  then  continues:) 


/>^,1    (*(r^.,e„.)°  A^fq:  q  e  IVP^(rp,m)}) 


(m,n)eE^       P  '  p 
m  calls  p 


'        P 

(m,n)eEl     (^{fg.:  q'  e  IVP^  (r^  .  ^e^,  )  }o  A  (fgi  q  c  IVP^(rp,m)}) 

m  is  a  call 
to  p' 

=    A  o  ^A^fq||(m,n)=  g  ^  IVP^(rp,m)})A 
(m,n)eE 

(ir.,n)eEl     ^^   ^^q  I  |(in,rp  . )  [  |q  '  |  |  (e^  .  ,n)  =  ^  ^  IVP^^^p'"^)' 

m  is  a  call  q'  g  lyp  (r  .,e  .)}) 

to  p  o   P   P 

It  is  easily  checked  that  for  each  function  f    appearing  in  the 
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last  right-hand  side,  q^  e  IVP^(r  ,n).   Hence,  this  last  right- 
hand  side  must  be 

>    {fgi  q  e  IVP^(rp,n)} 
The  same  inequality  is  then  seen  to  apply  to  the  limit  function 

To  prove  inequality  in  the  other  direction,  we  will  show  that 
for  each  q  e  IVPQ(rp,n),  f^  i  <!>  (j.  ^^y      This  will  be  proven  by 
induction  on  the  length  of  q.   If  this  length  is  0  then  n  must  be 
equal  to  r^  and  f^   =   (p^^    ^^  ^  =  id^^.   Suppose  that  the  assertion 
is  true  for  all  p,  n  and  all  q  e  IVP^(r  ,n)  whose  length  <_  k,  and 
let  there  be  given  p,  n,  q  such  that  the  length  of  q  is  k+1.   Let 
(m,n)  be  the  last  edge  in  q,  so  that  we  can  write  q  =  q  [ 1 (m,n) . 

If  (m,n)  e  E^  then  q^  e  IVP^(r  ,m)  and  its  length  is  <_  k. 
Therefore  f   i  */_    .    and  by  (3.2)  we  have 

^q  =  ^(m,n)°  fq3_  >  h(m,n)°  *(rp,m)  i  *(rp,n) 

If  (m,n)  e  E  ,  then  m  =  e  ,  for  some  procedure  p'.   It  is 
easily  seen  from  the  definition  of  IVP^,  that  q  can  be  decomposed 
as  q^l  I  (m^,rp,)  I  Iq^l  I  (ep,,n)  ,  such  that  {m^,n)  e  E""-, 

q,  c  IVP„(rp,.,).  gj  e  IVP„(rp,,ep,).   Since  f,^^,,^,,  ,   „,p,,„,  , 

id^  (since  m^  and  e^,  are  single  instruction  blocks,  containing 
only  an  interprocedural  branch  instruction) ,  we  have 

f  „  =  f  ^  °  f 

q   q2   qi 

But  both  q^   and  q^  have  length  _<  k,  so  that  by  (3.2)  and  the  in- 
duction hypothesis,  we  obtain 
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This  proves  our  assertion,  from  which  the  lemma  follows  immediately. 

Q.E.D. 
Let  us  now  define,  for  each  basic  block  n. 


3 


Pj.l'^3-1'         ^^P, 


Pj^  -  main  program,  p.  is  the  procedure  containing  n, 
and  for  each  i<j   c^  is  a  call  to  p._j_,  from  p.} 


(3.7)  z   =  V  (0) 

n   ^n  ^  ' 


Theorem  3.3;  i])^   =  x^^  for  each  n  e  N* . 


Proof:   Let  q  e  ^'^^  (^main'^^  '   ^^  Lemma  3.1  q  admits  a  decomposi- 
tion q  =  gil|(c^,rp  ) llq^ll...! I(Cj_i,rp  )  Hq^  as  in  (3.1),  i.e. 
there  exist  procedures  p^^  =  main  program,  p  ,  ...,  p.  =  the  pro- 
cedure containing  n,  and  calls  Cj_,...,c._^  such  that  for  each  i<j 
c^  is  a  call  to  p^^^^  from  p^,  and  q^  e  IVPQ(r   ,c^),  and  also 

^j  ^  ^^^o^^p.'^^- 

Thus ,  by  Lemma  3.2,  we  have 

q      qj     qj.i  ^i  - '(^p.^^)    ^(^p._^'^j-i)  °  •••  °  ^r^^^c^^) 


1  X 


n 


Hence ,    ii      >  Y  . 
n  —  '^n 


Conversely,  let  Pj^, . . .  ,Pj  ,c^, . . .  ,c  .  j^  be  as  in  (3.6).   By 
lemma  3 . 2  we  have 
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'^{r      ,n)''    *(r     ,c.  ,)°  •'•  °<^(r   ,c,  )  " 
Pj        Pj-1  ^  ^1 

A{f   of     o...of   :q.e  IVP_ (r   ,c. )  for  each  i<j  and 
'^   qj    qj_i        ^^i  ^1      o  Pi   1 

q.  C  IVP^Cr   ,n)} 
=    {f   I  I  ,       .11      I  I  ,        \  I  I   •  same  as  above} 

By  Lemma  3.1,  each  concatenated  path  in  the  last  set  expression 
belongs  to  IVP (r   .  ,n) .   Thus,  the  last  expression  is 


>  A  {f  :  q  e  IVP (r^^i^,n) }  =  ^^ 


Therefore  x      ^   i>      so   that  y   and  i)      are  equal  for  each  n  e  N* . 
'^n  —  n         '^n      n 

Q.E.D. 
We  can  now  prove  our  main  result: 

Theorem  3.4:   For  each  basic  block  neN*,x   =y   =z. 

n    n    n 

Proof:   It  is  immediate  from  Theorem  3.3  that  y   =  z   for  each 

n    n 

n  e  N* .   We  claim  that  x   =  ^    for  all  procedures  p  in  the 

^P     P 
program.   By  (3.3)  (c),  (3.6)  and  (3.7)  this  will  imply  that 

X  =  z   for  all  n. 
n    n 


To 


prove  our  claim,  we  define  a  new  flow  graph  G  =  (N  ,E  ,r,  ) , 

c       C   C   1 


where :N   is  the  set  of  all  entry  blocks  and  call  blocks  in  the 

program. 

E  =  E°  +  E   is  the  set  of  edges  of  G  .  An  edge  (m,n)  e  E„ 
c    c    c  c  c 

iff  m  is  the  entry  of  some  procedure  p  and  n  is  a  call  within  p. 
Moreover,  (m,n)  e  E    iff  m  is  a  call  to  some  procedure  p  and  n 
is  the  entry  of  p.   As  before,  ^-^    is  the  entry  block  of  the 
main  program.   We  now  define  a  data-flow  problem  for  G  by  associa- 
ting  a  data-propagating  map  g,    \  ^  ^  with  each  (m,n)  e  E  ,  in 
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such  a  way  that 

,o 


^(m,n) 


*(m,n)     i^  ^^'^^  ^  ^c 
idj^      if  (ni,n)  e  E^ 


It  is  clear  that  equations  (3.3) (a),  (3.3) (b)  are  equivalent  to 
the  iterative  equations  for  the  new  data-flow  problem.   On  the 
other  hand,  equations  (3.6)  and  (3.7)  define  the  meet  over  all 
paths  solution  for  the  same  problem,  if  we  substitute  only  entry 
blocks  or  call  blocks  for  n.   Since  F  is  assumed  to  be  distribu- 
tive, it  follows  by  Kildall's  theorem  [KI] ,  that  x   =  z    for 

P    ^P 
each  procedure  p,  and  this  completes  the  proof  of  our  theorem. 

Q.E.D. 

It  is  now  time  to  discuss  the  pragmatic  problems  that  will 
affect  attempts  to  use  the  fxinctional  approach  to  interprocedural 
analysis  that  we  have  sketched.   The  main  problem  is,  obviously, 
how  to  compute  the  4)'s  effectively  if  L  is  not  finite  (or  if  F  is 
not  bounded) .   As  examples  below  will  show,  in  the  most  general 
case  the  functional  approach  does  not  and  cannot  yield  an  effective 
algorithm  for  solving  equations  (3.2)  and  (3.3).   Moreover,  even 
if  the  iterative  computation  of  the  <|> '  s  converges,  we  must  still 
face  the  problem  of  space  needed  to  represent  these  functions. 
Since  the  functional  method  that  we  have  outlined  manipulates  the 
(j> '  s  directly,  instead  of  just  applying  them  to  elements  of  L,  it 
can  increase  the  space  required  for  data-flow  analysis  if  L  is 
finite,  and  may  even  fail  to  give  finite  representation  to  the  (fi's, 
if  L  is  infinite.   We  note  here  that  our  functional  approach 
belongs  to  the  class  of  elimination  algorithms  for  solving  data- 
flow problems  (a  class  of  methods  which  includes  the  interval- 
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oriented  algorithms  of  Cocke  and  Allen  [CA] ,  and  Tarjan's  fast 
elimination  algorithms  [TA2]),   since  it  uses  functional  compositions 
and  meets  in  addition  to  functional  applications.   All  such  elimina- 
tion algorithms  face  similar  problems,  and  in  practical  terms  are 
therefore  limited  to  cases  in  which  the  elements  of  F  possess  some 
compact  and  simple  representation,  and  in  which  F  is  a  bounded  semi- 
lattice.   This  family  of  cases  includes  the  classical  data-flow  prob- 
lems (i.e.  analysis  for  available  expressions,  use-definition 
chaining,  etc.;  cf.  [HE]). 

It  is  interesting  to  ask  whether  it  is  possible  to  modify  the 
functional  approach  so  that  it  avoids  explicit  functional  composi- 
tions and  meets,  and  thus  becomes  an  iterative  approach.   This  is 
possible  if  L  is  finite,  and  an  implementation  having  this  property 
will  be  sketched  below. 

The  following  example  will  illustrate  some  of  the  pragmatic 
problems  noted  above,  and  also  some  potential  advantages  of  the 
functional  approach  over  any  iterative  variant  of  it.   Suppose  that 
we  want  to  perform  constant  propagation  (see  e.g.  [HE]  for  a  des- 
cription of  the  standard  framework  used  in  this  analysis) .   Consider 
the  following  code : 
Example  2 

main  program         procedure  p 

^  •=  °'  if  cond  then 

call  P;  A  :=  A+1; 

print  A;  call  p; 

end;  A  :=  A-1; 

end  if; 
return;  end; 
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If  we  do  not  allow  symbolic  representation  of  the  (j>'s,  then, 

in  any  iterative  approach,  we  shall  have  to  compute  (})  ,      >({(A,0)}) 

^^p'^p) 

for  which  we  need  to  compute  (for  the  second  level  of  recursion) 

*(r  ,e  )(nA,l)})  etc.,  computing  ^.  <({(A,k)})  for  all  integers 

P  P  _  P   P 

k  >_  0.   Thus,  an  iterative  approach  would  diverge  in  this  example. 

However,  if  symbolic  or  some  other  compact  representation  of 
the  4)'s  is  possible,  then  it  can  be  advantageous  to  manipulate 
these  functions  directly,  without  applying  them  to  elements  of  L 
till  their  final  value  has  been  obtained.   This  can  give  us  an 
overall  description  of  their  behaviour,  allowing  them  to  be  calcu- 
lated in  relatively  few  iterations.   For  example,  in  the  example 

shown  above,  it  is  easily  checked  that  <|)  ,    ^  v  is  found  to  be  id. 

P'  P^  ^ 

after  two  iterations . 

However,  convergence  of  the  purely  functional  approach  is  not 
ensured  in  general.   To  see  this,  consider  the  following  slight 
modification  of  the  preceding  example. 
Example  3 

main  program        procedure  p 
A  :=  0'*  if  cond  then 

c^ll  P''  A  :=  A+2+sign(A-100)  , 

print  A;  call  p; 

end;  A  :=  A-1; 

end  if; 
return;  end; 
It  is  fairly  easy  to  check  that  the  purely  functional  approach 
(which  uses  symbolic  representation  of  the  <i>'s)    will  diverge  if 
negative  integers  are  included  in  the  program  domain.   Intuitively, 
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this  is  due  to  the  fact  that  it  takes  more  than  100+k  iterations 
through  Equations  (3.2)  to  detect  that  (^ ,  .   ({(A,-k)})  =  0   for 

all  k  >_  0. 

Remark ;   The  data-flow  framework  required  for  constant  propaga- 
tion is  in  general  not  distributive.   However,  it  can  be  shown  that 
the  standard  framework  for  constant  propagation  becomes  distributive 
if  the  program  contains  only  one  single  variable  and  each  propaga- 
tion between  adjacent  basic  blocks  either  sets  the  value  of  that 
variable  to  some  constant,  or  calculates  the  output  value  of  the 
variable  from  its  input  value  in  a  one-one  manner,  as  in  the  above 
examples. 

These  examples  indicate  that  if  L  is  not  finite,  divergence 
can  actually  occur.   If  L  is  infinite  but  F  is  bounded,  then  a  sym- 
bolic functional  approach  would  converge,  whereas  an  iterative 
approach  could  still  diverge  if  infinite  space  were  needed  to  repre- 
sent the  (|)'s.   Moreover,  we  have  at  present  no  simple  criterion 
which  guarantees  that  F  is  bounded  in  cases  in  which  L  is  infinite. 
For  these  reasons,  we  will  henceforth  assume  that  L  is  a  finite 
semilattice.   We  can  then  summarize  our  results  up  to  this  point  as 
follows: 

Corollary  3.5;  If  (L,F)  is  a  distributive  data-flow  framework  and 
the  semilattice  L  is  finite,  then  the  iterative  solution  of  Equations 
(3.2)  converges,  and  together  with  Equations  (3.3)  yields  the  meet 
over  all  interprocedurally  valid  paths  solution  (3.5). 

Next  we  shall  sketch  an  algorithm  which  implements  the  func- 
tional approach  for  frameworks  with  a  finite  semilattice  L.   We 
do  not  assume  that  any  compact  representation  for  elements  of  F  is 
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available,  but  instead  give  purely  iterative  representation  to  the 
functional  approach,  which  avoids  all  functional  compositions  and  meets 
and  also  computes  the  ^'s  only  for  values  which  reach  some  relevant 
procedure  entry  during  propagation. 

Our  algorithm  is  workpile-driven.   The  functions  (p    are  repre- 
sented by  a  two-dimensional  partially  defined  map  PHI:  N*  x  l  -»■  L, 

so  that  for  each  n  c  N*,  x  c  L,  PHI(n,x)  represents  <p  .  .  (x)  ,  where 

\  r  ,  n  J 

p  is  the  procedure  containing  n.   The  substeps   of  the  algorithm  are 
as  follows: 

1.  Initialize  WORK  :=  {(r,,0)},  PHI(rj^,0)  :=  0.   (WORK  is  a  subset 
of  N*  X  L,  containing  pairs  (n,x)  for  which  PHI(n,x)  has  been  changed 
and  its  new  value  has  not  yet  been  propagated  to  successor  blocks  of 
n.) 

2.  While  WORK  7^  0,    remove  an  element  (n,x)  from  WORK,  and  let 
y  =  PHI(n,x) . 

(a)  If  n  is  a  call  block  in  a  procedure  q,  calling  a  procedure 
p ,  then 

(i)   If  z  =  PHI (e  ,y)  is  defined,  let  m  be  the  unique  block 
such  that  (n,m)  e  E  ,  and  propagate  (x,z)  to  m.   (By  this 
we  mean:  assign  PHI(m,x)  :=  PHI(m,x)  /\  z,    where  undefined 
PHI(ra,x)  is  interpreted  as  ^;    if  the  value  of  PHI(m,x)  has 
changed,  add  (m,x)  to  WORK.) 

(ii)   Otherwise,  propagate  (y,y)  to  r  .   This  will  trigger 
propagation  through  p,  which  will  later  trigger  propagation 
to  the  block  following  n  in  q  (see  below) . 
(b)   If  n  is  the  exit  block  of  some  procedure  p,  i.e.  n  =  e  , 
find  all  pairs  (m,u)  such  that  m  is  a  block  following  some  call  c 
to  p,  and  PHI(c,u)  =  x,  and  for  each  such  pair  propagate  (u,y)  to  m. 
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(c)   If  n  is  any  other  block  in  some  procedure  p,  then,  for  each 
ni  e  Ep  {n},  propagate  (x,f  ^^^^^^^  (y)  )  to  m. 
3.   Repeat  step  2  till  WORK  =  0.      vVhen  this  happens,  PHI  represents 
the  desired  <j)  functions,  computed  only  for  "relevant"  data  values, 
from  which  the  x  solution  can  be  readily  computed  as  follows: 

X  =  A  PHI(n,a),  for  each  n  e  N*. 
^    acL 

Step  3  thus  implies  that  in  the  implementation  we  have  sketched 

separate  analysis  to  compute  the  x  solution   is  unnecessary. 

We  omit  analysis  of  the  above  algorithm,  which  in  many  ways 

would  resemble  an  analysis  of  the  abstract  approach.   However,  so 

as  not  to  avoid  the  issue  of  the  correctness  of  our  algorithm, 

we  outline  a  proof  of  its  total  correctness,  details  of  which  can 

be  readily  filled  in  by  the  reader.   The  proof  consists  of  several 

steps : 

I.  The  algorithm  terminates  if  L  is  finite,  since  each  element  (n,x) 
of  N*  X  L  (which  is  a  finite  set)  is  added  to  WORK  only  a  finite 
number  of  times,  because  the  values  assumed  by  PHI(n,x)  upon 
successive  insertions  constitute  a  strictly  decreasing  sequence  in 

L,  which  must  of  course  be  finite. 

II.  We  claim  that  for  each  n  e  n*, 

(1)  2C  1  A   PHI(n,a)   . 

acL 

To  prove  this  claim,  we  show,  using  induction  on  the  sequence  of 

steps  executed  by  the  algorithm,  that  at  the  end  of  the  i-th  step, 

x   <_  A  PHI''"(n,a),  for  each  n  e  N*,  a  e  L,  where  PHI"""  denotes  the 

acL 
value  of  PHI  at  the  end  of  the  i-th  step.   In  executing  the  i-th 
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step,  we  propagate  some  pair  (a,b)  e  L  x  L  to  some  n  e  N*.   By 
examining  all  possible  cases,  it  is  easy  to  show,  using  the  induc- 
tion hypothesis,  that  x^  <  b,  from  which  (1)  follows  immediately. 

III.   In  order  to  prove  the  converse  inequality,  it  is  sufficient, 

by  Theorem  3.4,  to  show  that  for  each  n  c  N*  and  q  e  IVP(r  ,n) , 

fg(0)  >   A   PHI(n,a).   To  do  this,  we  first  need  the  following 

a  c  Xj 
assertion: 

(*)   Let  p  be  a  procedure,  n  c  N^  and  a  c  L  for  which  PHI(n,a)  has 
been  computed  by  our  algorithm.   Then,  for  each  path  q  e  IVP  (r  ,n)  , 
f  (a)  >  PHI(n,a)  . 

Proof:   We  proceed  by  induction  on  the  length  of  q.   This  is  trivial 
if  the  length  =  0.   Suppose  that  it  is  true  for  all  p,  n,  a  and  q 
with  length  less  than  some  k  >  0,  and  let  q  c  IVP  (r  ,n)  be  of  length 
k.   Write  q  =  q|| (m,n)  and  observe  that  either  (m,n)  e  E°,  in  which 
case 

^q^^^  =  ^(m,n)(^q(^))  -  f(m,n)(P«^(^'^))  lPHI(n,a) 

(the  last  inequality  follows  from  the  structure  of  our  algorithm) , 
or  (m,n)  is  a  return  edge,  in  which  case  q  can  be  written  as 
qil  I  (c,rp.)  I  Iq^l  I  (m,n),  where  q^^  e  IVPQ(rp,c),  q^  c   IVP^  (r  ,  ,m)  , 
and  we  have 

^q^^^  =  ^q2^^qi^^^^  -  ^q  (PHI(c,a))  >  PHI  (m,PHI  (c,a)  )  >  PHI(n,a)  . 
IV.   Now  let  q  be  any  path  in  IVP(r^,n).   Decompose  q  as  in  (3.1) 


q   ^l\\^^l'^p^m-"\\(c^,r^^      )||qj+l.   Then, using  the  monotonicity 


of  F,  we  have 
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f   (0)  >  PHI(Cj_,0)  =  a^ 
%^W^^    -%^^1^    iPHI(c2,a^)  =  a^ 

(this  is  because  our  algorithm  will  propagate  (a,, a,)  to  r   ,  so 

P2 

that  PHI(c2,a^)  will  eventually  have  been  computed.)   Continuing  in 

this  manner,  we  obtain  f  (0)  >  PHI{n,a.),  which  proves  III.   This 

^  3 

completes  the  proof  of  the  total  correctness  of  our  algorithm. 

Example  4 :   Consider  Example  1  given  above.   The  steps  taken  by  our 
iterative  algorithm  are  summarized  in  the  following  table  (where, 
for  notational  convenience,  we  represent  PHI  as  a  set  of  triplets, 
so  that  it  contains  (a,b,c)  iff  PHI(a,b)  =  c) : 

d  to  PHI  WORK 

{(r^^/O)} 

{(Cj^,0)} 
{(r2,l)} 
{(C2,l) } 
{(C2/I)  ,  (62,1)} 
{(62,1) , (r2,0) } 
{(r2,0) ,(n^,0)} 
{(n^,0)  ,  (C2,0)} 
{(nj_,0)  ,  (C2,0),  (e2,0)  } 
{(C2,0),(e2,0) ,  (e^,0)} 
{(62,0) , (e^,0) , (n2,0)} 
{(e^,0) , (n2,0) , (n2,l)} 
{(e^,0) , (n2,0) , (n2,l)} 
{(n2,0)  ,  (n2,l)  } 
{(n2,l)} 


Propagate 

from 

to 

entries  ad 

initially 

•  (r^,0,0) 

(0,1) 

^1 

*=! 

(c^,0,l) 

(1,1) 

^1 

^2 

(r2,l,l) 

(1,0) 

^2 

""2 

(C2,l,0) 

(1,1) 

^2 

^2 

(e2,l,l) 

(0,0) 

°2 

^2 

(r2,0,0) 

(0,1) 

^2 

^1 

(n^,0,l) 

(0,0) 

^2 

^=2 

(C2,0,0) 

(0,0) 

^2 

^2 

(63,0,0) 

(0,1) 

^1 

^1 

(6^^,0,1) 

(0,0) 

^2 

^2 

(n2,0,0) 

(1,0) 

^2 

^2 

(n2,l,0) 

(0,0) 

^2 

^2 

- 

- 

^1 

- 

(0,1) 

^2 

^2 

- 

(1,1) 

^2 

^2 

- 
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Finally  we  compute  the  x  solution  of  Equations  (3.2,  3.3)  in  step  3  of 
our  iterative  algorithm  as  follows: 


X   =  PHI(r,  ,0)  =  0 
^1        ^ 

x^  =  PHKc,  ,0)  =  1 
^1        ^ 

X    =  PHI (n, ,0)  =  1 
"l         ^ 

X   =  PHI(e,  ,0)  =  1 
®1         ^ 

x^  =  PHI(r2,0)  A  PHI(r2,l)  =  0 

x^  =  PHI(C2,0)  A  PHI(C2,1)  =  0 

x^  =  PHI(n2,0)A  PHI(n2,l)  =  0 

Xg  =  PHI(e2,0)A  PHI(e2/l)  =  0 
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4.    The  call-string  approach  to  inter-procedural  analysi 


IS 


We  now  describe  a  second  approach  to  inter-procedural  analysis. 
This  approach  views  procedure  calls  and  returns  in  much  the  same 
way  as  any  other  transfer  of  control,  but  takes  care  to  avoid  propa- 
gation along  non-interprocedurally  valid  paths.   This  is  achieved  by 
tagging  propagated  data  with  an  encoded  history  of  procedure  calls 
along  which  that  data  has  propagated.   This  contrasts  with  the  idea 
of  tagging  it  by  the  lattice  value  attained  on  entrance  to  the  most 
recent  procedure,  as  in  the  functional  approach.   In  our  second 
approach,  this  'propagation  history'  is  updated  whenever  a  call  or  a 
return  is  encountered  during  propagation.   This  makes  inter- 
procedural  flow  explicit  and  increases  the  accuracy  of  propagated 
information.   Moreover,  by  passing  to  appropriate  but  simpler 
encodings  of  the  call  history,  we  are  able  to  derive  approximate, 
under-estimated  information  for  any  data-flow  analysis,  which  should 
nevertheless  remain  more  accurate  than  that  derived  by  ignoring 
all  inter-procedural  constraints  on  the  propagation.   The  fact  that 
this  second  approach  allows  us  to  perform  approximate  data-flow 
analysis  even  in  cases  in  which  convergence  of  a  full  analysis  is  not 
ensured  or  when  the  space  requirements  of  a  full  analysis  is  prohibi- 
tive, gives  this  second  approach  real  advantages. 

We  will  first  describe  our  second  approach  in  a  somewhat 
abstract  manner.   We  will  then  suggest  several  modifications  which 
yield  relatively  efficient  convergent  algorithms  for  many  important 


cases 


As  before,  we  suppose  that  v;e  are  given  an  interprocedural  flow 
graph  G,  but  this  time  we  make  an  explicit  use  of  the  second 
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representation  G*  =  (N*,E*,r,)  of  G.  I.e.,  we  do  blend  all  pro- 
cedures in  G  into  one  flow  graph,  but  distinguish  between  intra- 
procedural  and  inter-procedural  edges. 

Definition:   A  call  string  y  is  a  tuple  of  call  blocks  c,,c^,...,c. 

in  N*  for  which  there  exists  an  execution  path  q  c  IVP(r^,n), 

terminating  at  some  n  e  N*,  such  that  the  decomposition  (3.1)  of  q 

has  the  form  qilI(cT,r   ) | | q  . . . [ ] (c . ,r     )||q^,T  where 

-^    -^   P2     ^       3   Pj+1     3+1 

^i  ^  ^^o^^D  ''^i^  ^°^  ^^^^   i  1  3  ^<^   q-i  +  i  s  I^o^^r.    '")  •   To  show 
fi  J  J-      <->   Pj^-[_ 

the  relation  between  q  and  y   we  introduce  a  map  CM  such  that 


CM(q)  =  y.   By  the  uniqueness  of  the  decomposition  (3.1)  (cf. 
Lemma  3.1)  this  map  is  single-valued.   y  can  be  thought  of  as  the 
contents  of  a  stack  containing  the  locations  of  all  call  instruc- 
tions which  have  not  yet  been  completed,  in  an  implementation  that 
uses  such  a  device. 

Let  r  denote  the  space  of  all  call  strings  y  corresponding 
(in  the  above  sense)  to  interprocedurally  valid  paths  in  G* .   Note 
that  is  G*  is  non-recursive,  then  T   is  finite;  otherwise  T   will  be 
infinite,  and  as  we  shall  soon  see,  this  can  cause  difficulties  for 
our  approach. 

Let  (L,F)  be  the  data-flow  framework  under  consideration.   We 
define  a  new  framework  (L*,F*),  which  reflects  the  inter-procedural 
constraints  in  G*  in  an  implicit  manner,  as  follows: 

r 

L*  =  L  ,  i.e.  L*  is  the  space  of  all  maps  from  T   into  L.   Since 
we  assume  that  L  contains  a  largest  "undefined"  element  Q,    we  can 
identify  L*  with  the  space  of  all  partially  defined  maps  from  T   into 
L  -  {n}.   If  r  is  finite,  then  the  representation  of  L*  as  a  space 
of  partially  defined  maps  is  certainly  more  efficient,  but  for 


4.3 


abstract  purposes  the  first  representation  is  more  convenient. 
If  C  c  L*  and  y   c    T,    then  heuristically  ^ (y)  denotes  that  part  of 
the  propagated  data  which  has  been  propagated  along  execution  paths 
in  CM"-^{y}. 

If  we  define  a  meet  operation  in  L*  as  a  pointwise  meet  on  r,  i. 
if  for  C^,  ?2  e  L*,  Y  e  T,    we  define  (K^/\  ^^^  {y)    =   C-l  (y) A  ?2  ^^^  ' 
then  L*  becomes  a  semilattice.   The  smallest  element  in  L*  is  0*, 
where  0*(y)  =  0  for  each  y  ^  F.   The  largest  element  in  L*  is  Q* , 
where  n*  {y)    =  ^  for  each  y   c    T.      Note  that  unless  F  is  finite  L* 
need  not  be  bounded.   However,  if  ^-i  ^  Co  ^  •  •  •  ^  ^   >_  ...  is  an 
infinite  decreasing  chain  in  L*,  its  limit  is  well  defined  and  can 
be  computed  as  follows:   For  each  y   c   T,    the  chain 
C,  (y)  ^  ^2^^"^    —   '••    niust  be  finite  (since  L  is  bounded).   Define 

(lim  C  ) (y)  ss  the  final  value  of  that  chain.   Obviously  lim  E      = 
n  -^      ^n 

n 

A  C   and  in  the  same  manner  it  can  be  shown  that  A   C_  exists  for 

n   ^  n 

any  sequence  [E,.}.^,    in  L* . 

In  order  to  describe  F*  we  first  need  to  define  a  certain 

operation  in  F . 

Definition;   o :  F  x  E*  ->  F  is  a  partially  defined  binary  operation 
such  that  for  each  y   c   T   and  (m,n)  e  E*  such  that  CM~  {y)  '^ 
IVP(r,,m)  7^  ^  we  have 

Y       if  (ni,n)  e  E 


e.- 


Y»(in,n)  = 


y| I [m]   if  (m,n)  is  a  call  edge  in  E 
(i.e.  if  m  is  a  call  block) 

Y{1:#Y~1)   (i.e.  y  without  its  last  component) 
if  (m,n)  is  a  return  edge  in  E   such 


that  y(#Y)  is  its  corresponding  call  edge 
in  all  other  cases,  y  »  (in,n)  is  undefined. 
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The  following  lemma  can  be  proved  in  an  obvious  and  straightforward 
way. 

Lemma  4.1;   Let  y   c    T,     (m,n)  c  E*,  q  e  lVI>{r^,m)    such  that  CM(q)  =  y. 
Then  y^^  =  y  o  (m,n)  is  defined  iff  qj_  =  q  |  |  (ra,n)  is  in  IVP(r,,n),  in 
which  case  CM(q^)  =  y  . 

The  operation  ©  defines  the  manner  in  which  call  strings  are 
updated  as  data  is  propagated  along  an  edge  of  the  flow  graph. 
Loosely  put,  the  above  lemma  states  that  path  incrementation  is 
transformed  into  o  by  the  "homomorphism"  CM. 

Next,  let  (m,n)  c  E*,  and  let  f  (j^  n)  ^  ^  ^^  the  data-propagation 

map  associated  with  (m,n)  .   Note  that  by  our  assiomptions  f 

(in,n) 

i<^  if  (m,n)  c  E  ,  since  in  these  cases  m  is  a  block  containing 
only  a  jump  which  in  itself  does  not  affect  data  attributes. 
Define  f*^^^^^)  •*  L*  -^   L*  as  follows:   For  each  ?  c  L*,  y   c    T, 


%,n)  (^^  (^)  =  ' 


f  (in,n)  ^^^^1^  ^   if  there  exists  (necessarily 

a  unique)  y^^  such  that 

Yj_o(m,n)  =  y 


.^  otherwise 

The  intuitive  interpretation  of  this  formula  is  as  follows: 
^*m,n)  ^^^  represents  information  at  the  start  of  n  which  is  obtained 
by  propagation  of  the  information  5,  known  at  the  start  of  m,  along 
the  edge  (m,n)  .   For  each  Yj_  e  r  for  which  CCy^)  is  defined,  we 
propagate  C  (Y^)  /  the  Yj_-selected  data  available  at  the  start  of  m, 
to  the  start  of  n  in  standard  intra-procedural  fashion  (that  is, 
using  ^f^^^^^)-      However,  this  propagated  data  is  now  associated 
not  with  y^   but  with  y^  o  (m,n) ,  which  "tags"  the  set  of  paths  ob- 
tained by  concatenating  (m,n)  to  all  paths  which  are  "tagged"  by 
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Y,  /  which  lead  to  m,  and  along  which  ?(Y-i)  has  been  propagated. 

If  Y-i  o  (ni,n)  is  undefined,  then,  by  Lemma  4.1,  C(Yi)  should  not  be 

propagated  through  (m,n)  since  no  path  which  leads  to  m  and  is 

tagged  by  y-i  can  be  concatenated  with  (m,n)  in  a  inter-procedurally 

valid  manner.   In  this  case,  we  simply  discard  f  ,_   ,  (5  (Yt ) )  as  is 

(ni,n)     1 

indicated  by  the  above  formula. 

F*  is  now  defined  as  the  smallest  subset  of  maps  acting  in  L* 
which  contains  (f*/    v  :  (m,n)  c   E*}  and  the  identity  map  in  L*  and 
which  is  closed  under  functional  composition  and  meet. 

Lemma  4.2:   (a)  If  F  is  monotone  in  L,  then  F*  is  monotone  in  L*. 

(b)  If  F  is  distributive  in  L,  then  F*  is  distributive  in  L*. 

(c)  If  F  is  distributive  in  L,  then  for  each  (m,n)  c  E,  f*    ,  is 

\m  ,n ; 

continuous  in  L*,  that  is/f*    \  (  .A  ?,  )  =  A   f^_   \  (C,  )  /  for  each 
(m,n)   ,   k     O    (m,n)   k 


k   ^     k 


collection  ^^5i,^v>i  S  L*« 


Proof:   It  is  easily  seen  that  it  is  sufficient  to  prove  (a)  or  (b) 

for  the  set  {f*/_  _^  :  (m,n)  e  E*},  and  this  is  straightforward  from 

vm ,  n^ 

the  definitions. 

To  prove  (c) ,  note  that  for  each  y   c    T    for  which  there  exists 
Y->  c  r  such  that  Yi  «  (ni,n)  =  y  we  have 

(m,n)  k>l  ^        ^^'^'    k>l  ^  ^ 


Buf  since  L  is  bounded,  there  exists  k  (y-,)  such  that  the  last 

(m,n) 
distributivity  of  f,    ^equals 


expression  equals  f/j^  j^nI  /\       ^k  ^'''l^  ^  '  ^^^^^  ^^  turn,  by  the 


l<k<.k^(Yi) 
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A   ,_  f,„,n)'5k<Vl)) 


l<k<k^(Y^) 


Thus  f^^  „.  {./\  Cv)  >  /\  ft„  „\  (Cu)  •   The  converse  inequality  is 
vni/n;  ],>i   •'^   —  k>l   v"i/n;   k 

immediate  from  the  monotonicity  of  f*    ,.  Q.E.D. 

(m,n) 

Remark ;   Note  that  inter-procedural,  as  distinct  from  intra- 
procedural,  data-flow  frameworks  depend  heavily  on  the  flow-graph 
(r  itself  may  vary  from  one  flow  graph  to  another).   Thus,  for 
example,  there  is  no  simple  way  to  obtain  F*  directly  from  F  without 
any  reference  to  the  flow  graph.   This  will  not  create  any  problems 
in  the  sequel,  and  we  argue  that  even  in  the  intra-procedural  case 
it  is  a  better  practice  to  regard  data-flow  frameworks  as  graph 
dependent. 

We  can  now  define  a  data-flow  problem  for  G* ,  using  the  new 
framework  (L*,F*) ,  in  which  we  seek  the  maximal  fixed  point  solu- 
tion of  the  following  equations  in  L* : 


(4.1) 


x*   =  {(X,0)}  ,  where  X    is  the  null  call  string 

X*  =    /\    f*     (x*)  ,   n  e  N*  -  {r,  } 
^    (ra,n)cE*   ("''^^   ^  1 

We  can  show  the  existence  of  a  solution  to  those  equations 


in  the  following  manner:   Let  x*^°^  =  {(X,0)},  x*  ^°^  =  CI*    for  all 

r^  n 

n  eN*  -  {r^}.   Then  apply  Equations  (4.1)  iteratively  to  obtain 

new  approximations  to  the  x* '  s .   Let  x*^"^'  denote  the  i-th  approx- 

n 

imation  computed  in  this  manner. 
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Since  x*  ^    -  ^n     ^°^   ^'^'^   n  c  N*,  it  follows  inductively, 

from  the  monotonicity  of  f*     for  each  (in,n)  e  E*,  that 

vin  f  n  j 

^n    -  ^*n  "*"    ^°^   ^-^-^   i  >_  0,  n  e  N*.   Thus,  for  each  n  c  N*, 
tx*    ■^i>o  ^^   ^   decreasing  chain  in  L* ,  having  a  limit,  and  we 
define  x*  =  lim  x*^"""  .   It  is  rather  straightforward  to  show  that 
^^n^'^ncN*  ^^    indeed  a  solution  to  (4.1)  and  that  in  fact  it  is  the 
maximal  fixed  point  solution  of  (4.1). 

Having  defined  this  solution,  we  will  want  to  convert  its 
values  to  values  in  L,  because  L*  has  been  introduced  only  as  an 
auxiliary  semilattice,  and  our  aim  is  really  to  obtain  data  in  L 
for  each  basic  block.   Since  there  is  no  longer  a  need  to  split  the 
data  at  node  n  into  parts  depending  on  the  interprocedural  flow 
leading  to  n,  we  can  combine  these  parts  together,  i.e.  take  their 
meet.   For  each  n  e  N*,  we  can  then  simply  define 

(4.2)  ^A  =  A  x*(Y) 

In  justifying  the  approach  that  we  have  just  outlined  our  first 
step  is  to  prove  that  x^  coincides  with  the  meet  over  all  inter- 
procedurally  valid  paths  solution  y   defined  at  the  previous  sec- 
tion.  This  can  be  shown  as  follows: 

Definition;   Let  path^^(r^,n)  denote  the  set  of  all  execution  paths 
(whether  interprocedurally  valid  or  not)  leading  from  r,  to  n  e  N*. 
For  each  p  =  (r^  , S2  ,  .  .  . , Sj^ ,n)  e  path2*(r^,n)  define 

%   =  ^\,n)   °  ^\.^,s^)     •••  °^(r^,S2)  •   ^°^  ^^^^  ^  ^  N*  define 
y*  =  /\{f*(x*  ):  p  c  pathQ^(r^,n)}. 

Since  pathj^^  (rj^,n)  is  at  most  countable,  this  (possibly 
infinite)  meet  in  L*  is  well-defined. 
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Theorem  4.3;   If  (L,F)  is  a  distributive  data-flow  framework  then, 

for  each  n  c  N*,  x*  =  y*. 

n    n 

Proof:   (VJhich  is  quite  similar  to  the  proof  of  an  analagous  theorem 

of  Kildall  for  a  bounded  semilattice  [KI]): 

(a)   Let  n  c  N*  and  p  =  (r,  ,3- / .  •  -  » s,  ,n)  e  path  ^(r,,n).   By  (4.1) 


we  have 


X*   <  f* ,      , (x*  ) 

S2  -    (r3_,S2)   r^^ 


X*   <  f*      >  (x*  ) 
^3     ^^2'^3^   ^2 


X*  <  f*     , (x*  ) 
n  -   (Sj^,n)  s^' 


Combining  all  these  inequalities,  and  using  the  monotonicity  of 

the  f*'s  we  obtain  x*  <  f * (x*  ),  and  therefore  x*  <  y*. 

n  —  p '  r,  n  —  -'n 

(b)   Conversely,  we  will  prove  by  induction  on  i  that 

x*^^^  >  y*  for  all  i  >  0,  n  G  N*   . 
n    —  ■'  n  — 

Indeed,  let  i=0.   If  np^r,  then  x*^^'    =   ^*    >   y* .      On  the  other  hand. 

In         —  ■'n 

the  null  execution  path  p-  e  path_^ (r, ,r, ) ,  so  that  y*   <  f*  (x*  )  = 

^    ^0    '^    G*  '  1'  1''         -'r,  —  p-   r, 
(0)  u    X 

X*   =  X*    .   Thus  the  assertion  is  true  for  i=0 .   Suppose  that  it 

11  .  . 

is  true  for  some  i>0.   Then  x*     '    =   x*   '  >  y*  ,  and  for  each 

^1        ^1   -  ^1 
n  c  N*  -  {r, }  we  have 


x 

n 


*(i+l)  =    A    f*     (x*^^^  >    A   f*     (V*) 


by  the  induction  hypothesis.   We  now  need  the  following 

Lemma  4.4:   For  each  (m,n)  e  E*,  f*    .  (y*)  >  y*. 
(m,n)  -"m  —  -'n 
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Proof:   Since  f*    ,    is  distributive  and  continuous  on  L*  (Lemma  4.2), 
we  have 

=  ^^^Un)     (f;(^*^))=  P  ^  Path^*  (ri,m)} 

1  A^f5(^*  )=  q  c  path^,*  {rj_,n)}  =  y* 

Q.E.D. 

Now  returning  to  Theorem  4 . 3  it  follows  by  Ler.ima  4.4  that 

^n      1    /  \    y*  =  y*   (each  n  c  N*  is  assumed  to  have  pre- 
^        (m,n)eE*   ^    n 

decessors) .   Hence  assertion  (b)  is  established,  and  it  follows  that 

for  each  n  £  N*   x*  =  lim  x*^^^  =  A  x*^^^  >  y*,  so  that  x*  =  v* . 

"    j_   n      ^^^      n    —  "n  n   -'n 

Q.E.D. 

Lemma  4.5;   Let  n  e  N*,  p  =  (r^,S2 ,  •  -  .  ,Sj^,n)  e  pathg^(r^,n)  and 

Y  e  r.   Then  f*(x*  ) (y)  is  defined  iff  p  e  IVP(r^,n)  and  CM(p)  =  y. 

If  this  is  the  case,  then  f *  (x*  )  (y)  =  f  (0). 

p   r, '  ^  ' '     p  ^"'  • 

Proof:   The  proof  is  by  induction  on  £ (p) ,  the  length  of  p  (i.e.  the 

number  of  edges  in  p) .   If  p  is  the  null  path,  then  n  must  be  equal 

to  r^ .   Moreover,  CM(p)  =  A,  p  e  IVP(r, ,r, )  and  f*(x*  )  =  x*   is 
■^  ■'•   l       P   ^1     P]_ 

defined  only  at  A  and  equals  0  =  f  (0) .   Thus  our  assertion  is  true 
if  Jl(p)  =  0. 

Suppose  that  this  assertion  is  true  for  all  n  e  N*  and 
p  e  pathg^(r^,n)  such  that  i {p)    <    X.      Let  n  e  N*  and  p  = 
(rj^,S2,  .  . .  ,Sj^,n)  be  a  path  of  length  k  in  path^(r,,n).   Let 
1?2.   ~    (^i'^2' *  *  * '^k^  *   ^^  definition,  for  each  y  e  F  we  have 
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f*(x*  ) (Y) 
p   r  ' 


*U,,,n)tf;/==J,'l<V) 


(, 


1^      „^  tf*  (^t  )(Yi)1  if  there  exists 
(Sj^^n)   p^   r^    1    ^_^  ^  J,  3^^j^  ^^^^ 

Y-,  "  (s,n)  =  Y 
k 
fl  otherwise 


Thus  f * (x*  ) (y)  is  defined  iff  there  exists  y,    c    7   such  that 
p   r-|  1 

Yi  o  (m,n)  =Y  and  f*  (x*  ) (Y, )  is  defined.  By  our  inductive  hypothesis, 

-L  Pr   ^1    -^ 

this  is  the  case  iff  p,  e  IVP(r,,s,),  CM(p,)  =  Y-i  and  Yi  «  (s  ,n)  =  y- 

By  Lemma  4.1,  these  last  conditions  are  equivalent  to  p  e  IVP(r,  ,n) 

and  CM(p)  =  Y« 

If  this  is  the  case,  then  again,  by  our  inductive  hypothesis, 

f*  (x*  ) (Yn)  =  f„  (0)  and  so 
Pi   ^1    ^  ^1 


f*(xJ^)(Y)  =f(,^,n,lSi""l  =S"" 


Now  we  can  prove  the  main  result  of  this  section; 

Theorem  4.6:   For  each  n  c  N*,  x'  =  y  . 
n   -'n 


Proof:   Let  y   c   V.      By  Theorem  4.3, 


Q.E.D, 


x*(Y)  = 


{f*(x*  )  (Y)  :  p  e  pathg^(rj_,n)  } 


and  by  Lemma  4 . 5 


=  A{f  (0):  p  c  IVP(r,  ,n)  such  that  CM(p)  =  y) 


Thus,  by  (4.2) , 


K"    ^    ^A^^^  =  Atfp(O):  p  e  IVP(r^,n)}  =  y^ 
YGl 


Q.E.D. 
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Corollary  4.7:   If  the  flow  graph  G*  is  non-recursive  then  the 
iterative  solution  of  Equations  (4.1)  that  we  have  described  will 
converge  and  yield  the  desired  meet  over  all  interprocedurally 
valid  paths  solution  of  these  equations. 

Proof:   Convergence  is  assured  since  T   is  finite  and  hence  L*  is 
bounded.   Thus  (L*,F*)  is  a  distributive  data-flow  framework  and 
by  standard  arguments  the  iterative  solution  of  (4.1)  must  converge 
(cf.  [KI]  or  [HE]).   Therefore,  Theorem  4.6  implies  that  the 
limiting  solution  coincides  with  the  meet  over  all  paths  solution. 

Q.E.D. 

The  call-strings  approach  is  of  questionable  feasibility  if  r 
is  infinite,  i.e.  if  G*  contains  recursive  procedures.   Moreover, 
just  as  for  the  functional  approach,  it  is  rather  hopeless  to  convert 
the  call  strings  approach  into  an  effective  algorithm  for  handling 
the  most  general  cases  of  certain  data-flow  problems  such  as  con- 
stant propagation.   However,  as  we  shall  see  in  the  following  sec- 
tion, a  fairly  practical  variant  of  the  call  strings  approach  can 
be  devised  for  data-flow  frameworks  with  a  finite  semilattice  L. 
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5 .    Data-flow  analyses  using  a  finite  semilattice 

Let  (L,F)  be  a  distributive  data-flow  framework  such  that  L  is 
finite.   As  we  have  seen,  the  functional  approach  described  in 
Section  3  converges  for  such  a  framework.   We  will  show  in  this 
section  that  it  is  also  possible  to  construct  a  call-strings  algo- 
rithm which  converges  for  these  frameworks.   As  noted  in  the  previous 
section,  convergence  is  ensured  if  T   is  finite.   The  idea  behind  our 
modified  approach  is  to  replace  r  by  some  finite  subset  r^^  and  allow 
propagation  only  through  inter-procedurally  valid  paths  which  are 
mapped  into  elements  of  Tq.   Such  an  approach  is  not  generally 
feasible  since  it  can  lead  to  an  over-estimated  (and  unsafe)  solution, 
since  it  does  not  trace  information  along  all  possible  paths.   How- 
ever, using  the  finiteness  of  L,  v:a  will  show  that  T^   can  be  chosen 
in  such  a  way  that  no  information  gets  lost  and  the  algorithm  comes 
up  with  an  acceptable  solution. 

We  begin  to  describe  our  approach  without  fully  specifying  T,, . 
Later  we  will  show  how  T^    should  depend  on  L  in  order  to  guarantee 
an  acceptable  solution. 


Definitions:  (a)  Let  r^  be  some  finite  subset  of  T   with  the  property 
that  if  Y  c  Tq  and  y-j_  is  an  initial  sxibtuple  of  y,  then  y,  e  T-  too. 
(b)   For  each  n  e  N*,  let  IVP'(r  ,n)  denote  the  set  of  all 
q  e  IVP  (r^^  ,n)such  that  for  each  initial  subpath  q,  of  q  (including  q)  , 
CM(q^)  e  Tq. 


Yo(m,n)  = 


(c)   We  also  modify  the  e    operation  so  that  it  acts  in  r   rather 
than  in  T,    as  follows:   If  y  e  T^,  (m,n)  c  E*  such  that  there  exists 
q  c  IVP'(rj_,in)  where  CM(q)  =  y,    then 

''y       if  (in,n)  e  E° 

yI  I  [rn]   if  (m,n)  is  a  call  edge  in  E   and 
YlUm]  e  Tq 

Y(1:  #Y-1)   if  (in,n)  is  a  return  edge  in  E   and 
Y(#y)  is  the  call  block  preceding  n 

undefined  in  all  other  cases 

The  only  difference  between  this  definition  of  o  and  the  previous 
one  is  that  it  will  not  add  a  call  block  m  to  a  call  string  y 
unless  the  resulting  string  is  in  Fq.   When  this  is  not  the  case, 
information  tagged  by  y  will  be  lost  when  propagating  through 
(m,n) ,  unless  it  is  also  tagged  by  some  other  call  string  to  which 
m  can  be  concatenated.   The  following  lemma  is  analogous  to  Lemma 
4.1: 

Lemma  5.1:   Let  y   e  T^,     (m,n)  e  E*,  q  c  IVP'(rj_,m)  such  that 

CM(q)  =  Y-   Then  Y^  =  Y   (m,n)  is  defined  iff  q^  =  q| | (m,n)  is  in   - 

IVP'(rj^,n),  in  which  case  CM(q,)  =  y-,  . 

We  now  define  a  data-flow  framework  (L*,F*)  in  much  the  same 
way  as  in  Section  4,  but  replace  T  by  r  .  This  leads  to  a  bounded 
semilattice  L*  =  L   and  to  a  distributive  data-flow  framework 
(L*,F*) . 

Hence,  Equations  (4.1)  come  to  be  effectively  solvable  by  any 
standard  iterative  algorithm  which  yields  their  maximal  fixed 
point  solution.   To  this  solution  we  will  want  to  apply  the 
following  final  calculation,  which  is  a  variant  of  (4.2): 
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(5.1)  x^  =  A   x*(  ) 

0 


"   YcK   ^ 


Careful  scrutiny  of  the  analysis  of  the  previous  section  re- 
veals that  the  only  place  where  the  nature  of  r   and  the  operation 
o  are  referred  to  is  in  Lemma  4.1,  and  it  is  easily  seen  that  if  we 
replace  T   and  o  by  r^  and  the  modified  o  ,  throughout  the  previous 
analysis,  and  also  replace  IVP(r^,n)  by  IVP'(r^,n)  for  all  n  c  N*, 
then  by  proofs  completely  analogous  to  those  presented  in  Section  4 
(but  with  one  notable  difference,  i.e.  that  there  is  now  no  need  to 
worry  about  continuity  of  F*  or  infinite  meets  in  L*,  since  L*  is 
now  known  to  be  bounded) ,  we  obtain  the  following: 

Theorem  5.2:   For  each  n  e  N* 

^^   =  Y'n    =    A{fp(0):  p  c  IVP-  (rj_,n)} 

Up  to  this  point,  our  suggested  modifications  have  been  quite 

general  and  do  not  impose  any  particular  requirements  upon  L  or 

upon  r  .   On  the  other  hand.  Theorem  5.2  implies  that  x"  is  an  over- 

n 

estimated  solution,  and  as  such  is  useless  for  purposes  of  our 
analysis,  as  it  can  yield  unsafe  information  (e.g.  may  suggest  that 
an  expression  is  available  whereas  it  may  actually  be  unavailable) , 
unless  we  can  show  that  x^  coincides  with  the  meet  over  all  inter- 
procedurally  valid  paths  solution  of  the  attribute-propagation 
equations  which  concern  us.   As  will  be  shown  below,  this  is  indeed 
the  case  if  L  is  finite. 

Definition:   Let  M  >  0  be  an  integer.   Define  T^   as  the  (finite) 

set  of  all  call  strings  whose  length  does  not  exceed  M.   r„ 

M 
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obviously  satisfies  the  conditions  of  part  (a)  of  the  previous 
definition. 

Lemma  5.3;   Let  (L,F)  be  a  data-flow  framework  with  a  finite  semi- 

lattice,  and  let  M  =  K{|l|+1)  ,  where  K  is  the  number  of  call  blocks 

in  the  program  being  analyzed  and  |l|  is  the  cardinality  of  L. 

Let  r   =  r...   Then,  for  each  n  c  N*  and  each  execution  path 
o    M 

q  c  IVP(r,,n)  there  exists  another  path  q'  c  IVP'(rj^,n)  such  that 
f  (0)  =  f  .  (0)  • 

q     q 

Proof:   By  induction  on  the  length  of  q.   If  the  length  is  0  then 
n=r,  and  q  is  the  null  execution  path,  which  belongs  to  both 
IVP(r,,r,)  and  IVP'(r,,r,),  so  that  our  assertion  is  obviously  true 
in  this  case. 

Suppose  that  the  lemma  is  true  for  all  paths  whose  length  is 
less  than  some  k>_l ,  and  let  n  e  N*,  q  e  IVP(r,,n)  be  a  path  of 
length  k.   If  q  e  IVP ' (r, ,n)  then  there  is  nothing  to  prove,  so 
assume  that  this  is  not  the  case,  and  let  q   be  the  shortest  ini- 
tial subpath  of  q  such  that  CM(q  )  ^    T    .      Then  q   can  be  decomposed 
according  to  (3.1)  as  follows: 

q^  =  qjl(c^,rp^)llq2|l  ...  i  I  (<=  j  '  ^p  ._^^H  I  qj+i 


Hen 


ce  j>M.   Next,  consider  the  sequence  {  (c  ,a.  ,B  . )  )  •_-|  /  where, 


for  each  i<j ,  a.  =  f   of     ...   of   (O)  ,  and  3-  is  either  U.   if 

-   1   qi   qi.i      qi       i 

the  call  at  c.  is  not  completed  in  q  (this  call  is  certainly  not 
completed  in  q^) ,  or  f^  (0)  if  the  call  at  c.  is  completed  in  q, 
and  q.  is  the  initial  subpath  of  q  ending  at  the  return  which 
completes  the  call.   Thus,  for  each  call,  the  sequence  records  the 
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calling  block,  the  value  propagated  along  this  path  until  the  call, 

and  the  value  propagated  until  the  corresponding  return,  if  it 

materializes.   The  number  of  distinct  elements  of  such  a  sequence 

is  at  most  K(|l|+1)   =  M  (we  do  not  count  n  as  an  element  of  L;  if 

we  did,  then  the  bound  can  be  reduced  to  K|l|  ).   Since  j>M,  this 

sequence  must  contain  at  least  two  identical  components 

(c.  ,a.  ,3-  )  and  (c.  ,a   ,6   ),  where  i,<i-,<j. 
^1   ^1   ^1         ^2   ^2   ^2  ^      ^ 

Now,  if  0.   =0.   =  fl,  then  neither  of  the  calls  c.  ,  c.   is 
^1     ^2  ^1    ^2 

completed  in  q.   If  we  rewrite 

q  =  q^lKc.  ,r     )||q'||(c   ,r     )llq' 

^  ^1  Pi+1    ^    ^2   Pi+1    -^ 

1  2 

then  it  is  easily  seen  that  the  shorter  path  q  =  q'II(c.  ,r    )\\'3.2 


•1  ^i+1 


is  also  in  IVP(r,,n).   Moreover 


a^   =  f  ,  (0)  =  a   =  f   o  f   (0) 
J-1    ^1         ^2     ^2        ^1 


so  that 


By  our  induction  hypothesis  there  exists  q'  e  IVP'(r,,n)  such  that 

fgi (0)  =  fg{0)  =  f  (0),  which  proves  the  lemma  for  q. 

On  the  other  hand,  if  6.   =  B.  fi  ^,    then  it  follows  that  both 

^1    ^2 
calls  c.   and  c.   are  completed  in  q,  with  c.   necessarily  completed 

^1      ^2  ^2 

first.   Thus  we  can  write 

1  2  2 


(e     ,n   )||q' 

Pi+1  ^1 

1 
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where  n.   =  n.   is  the  block  immediately  following  c  .   Again  it 

^1     ^2  ^1 

follows  that  q  =  q,'  I  I  (c.  ,r     |  |q!,|  |  (e^    ,n.  )  |  |q'  is  in 

^  ^1     Pi+1   -^    Pi+1   ^1    ^ 

1  1 

IVP(r,,n).   Moreover 

a.   =  f  .  (0)  =  a   =  f   of   (0) 
^1     ^1        ^2     ^2    ^1 

3,-  =f„,of,of  of,(o)=e.  =f,cf,of,(o) 

^1     ^4    ^3    ^2    ^1        ^2     ^3    ^2    "^1 

from  which  one  easily  obtains  f  (0)  =  f  (.0)  ,    and  the  proof  can  now 
continue  exactly  as  before. 

Q.E.D. 
The  main  result  of  this  section  now  follows  immediately: 

Theorem  5.4:   Let  (L,F)  be  a  distributive  data-flow  framework  with 
a  finite  semilattice  L,  and  let  T     =   T.,,    with  M  as  defined  above. 

O      M 

Then,  for  each  n  e  N*,  x"  =  y  .   That  is,  the  modified  algorithm 

n    n  ^ 

described  in  the  first  pages  of  the  present  section  yields  a  valid 
inter-procedural  solution. 

Proof:   Since  IVP'{r, ,n)  c  lVP(r, ,n)  we  have  x"  >  y  .   On  the  other 
J.  1  n  —  n 

hand,  let  q  c  IVP(r^,n).   By  Lemma  5.3  there  exists  q'  e  IVP'(r,,n) 
such  that  f  (0)  =  f  ,  (0)  >    i^r,^^^'    P  ^  IVP'(r,  ,n)}  =  x" .   Hence 
Yj^  =  A  tf  (0)  :  q  c  IVP(rj_,n)  }  >_  x^. 

Q.E.D. 

Remark :   Note  that  in  Lemma  5 . 3  and  Theorem  5.4  K  can  be  replaced 
by  the  maximal  number  K'  of  distinct  calls  in  any  sequence  of 
nested  calls  in  the  program  being  analyzed.   In  most  cases  this 
gives  a  significant  improvement  of  the  bound  on  M  appearing  in 
these  two  results. 
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We  have  now  shown  that  finite  data-flow  frameworks  are  solvable 

by  a  modified  call-strings  approach.   However,  the  size  of  T      can 

be  expected  to  be  large  enough  to  make  this  approach  as  impractical 

as  the  corresponding  functional  approach.   But  in  several  special 

cases  we  can  reduce  the  size  of  F   still  further. 

o 

Definition:   A  data-flow  framework  (L,F)  is  called  decomposable 

if  there  exists  a  finite  set  A  and  a  collection  of  data-flow 

frameworks  { (L  ,F  ) }   .,  such  that 
a   a   aeA 

(1)  L  =  "1  T  ^  '  ordered  in  a  pointwise  manner  induced  by  the 

acA 

individual  orders  in  each  L  . 

a 

(2)  F  c  S  F  .   That  is,  for  each  f  e  F  there  exists  a  collection 

acA 

{f'^}   -  where  f   c  F   for  each  a  c  A,  such  that  for  each 
aeA 

X  =  (x  )   -  c  L  we  have 
a   acA 

In  the  cases  covered  by  this  definition  we  can  split  our  data- 
flow framework  into  a  finite  number  of  "independent"  frameworks, 
each  inducing  a  separate  data-flow  problem,  and  obtain  the  solu- 
tion to  the  original  problem  simply  by  grouping  all  the  individual 
solutions  together. 

For  example,  the  standard  framework  (L,F)  for  available  expres- 
sions analysis  is  decomposable  into  subframeworks  each  of  which  is  a 
framework  for  the  availability  of  a  single  expression.  Formally,  let 
A  be  the  set  of  all  program  expressions.   For  each  aeA  let 
L  =  {0,1}  where  1  indicates  that  a  is  available  and  0  that  it  is 
not.   Then  {0,1}   is  isomorphic  with  L  (which  is  more  conveniently 
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represented  as  the  power  set  of  A) .   It  is  easily  checked  that  each 

f  c  F  can  be  decomposed  as  ©  f*^,  where  for  each  a  c  A   f"^  e  F  , 

aeA  ^ 

and  is  either  the  constant  0  if  a  can  be  killed  by  the  propagation 

step  described  by  f,  f   is  the  constant  1  if  a  is  unconditionally 
generated  by  that  propagation  step,  and  is  the  identity  map  in  all 
other  cases.   The  frameworks  used  for  use-definition  chaining  and 
live  variables  have  analogous  decompositions. 

A  straightforward  modification  of  Lemma  5.3,  applied  to  each 
(L(^/F^)  separately  yields  the  following  improved  result  for  decom- 
posable frameworks: 

Theorem  5.5:   Let  (L,F)  be  a  decomposable  distributive  data-flow 

framework  with  a  finite  semilattice.   Define  M  =  K-max(|L  1+1)^ 

acA 

and  let  T      =   T    .      Then,  for  each  n  e  N*,  y"  =  y  . 
on  n    n 

In  the  special  case  of  available  expressions  analysis  this  is 
certainly  an  improvement  of  Theorem  5.4,  since  it  reduces  the  bound 
on  the  length  of  permissible  call-strings  from  K-0(4''^')  to  9K. 
For  this  analysis  we  can  do  even  better  since  available  expression 
analysis  has  the  property  appearing  in  the  following  definition. 

Definition:   A  decomposable  data-flow  framework  {L,F)  is  called 
1-related  if,  for  each  aeA,  F^  consists  only  of  constant  functions 
and  identity  fionctions. 

This  property  is  characteristic  of  situations  in  which  there 
exists  at  most  one  point  along  each  path  which  can  affect  the  data 
being  propagated.   Indeed,  consider  a  framework  having  this  property, 
let   e<€A  and  let  p  =  {s^fS^,-  -  .  ,s^)    be  an  execution  path.   Let  j<k 
be  the  largest  index  such  that  f  /_      .  is  a  constant  function. 

lSj_j^,Sj) 

Then  clearly  f=f,       ^         ^    ■      ^-u        ^  ,         ^^tt 

p      ^^i-l'^i^  ^    -^^  therefore  also  a  constant.  Hence  i 
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this  case  the  effect  of  propagation  in  L   through  p  is  independent  of 

the  initial  data  and  is  determined  by  the  edge  (s._,,s.)  alone. 

If  no  such  j  exists,  then  f   =  id|   ,  in  which  case  no  point  along 

P      -^a 

p  affects  the  final  data. 

Note  also  that  since  each  F^  is  assumed  to  be  closed  under 
functional  meet,  it  follows  that  if  (L,F)  is  1-related  then  the 
only  constant  functions  that  F;^  can  contain  are  0  (the  smallest 
element  in  L  )  and  1  (the  largest  element) .   Hence  we  can  assume, 
with  no  loss  of  generality,  that  L   is  the  trivial  lattice  {0,1} 
for  each  a  c  A.   All  the  classical  data-flow  analyses  mentioned 
above  have  1-related  frameworks. 

For  frameworks  having  the  1-related  property  it  is  easy  to 

replace  an  execution  path  q  by  a  shorter  subpath  q  such  that 

a       a 
f^(0)  =  f_.(0)  for  some  a  e  A.   Indeed,  to  obtain  such  a  q  we  have 

A 

only  to  ensure  that  q  is  also  inter-procedurally  valid  and  that  the 

last  edge  (s,s')  in  q  for  which  f ,    i v  is  constant  belongs  to  q. 

I  s  /  s  ) 

This  observation  allows  us  to  restrict  the  length  of  permissible 
call  strings  still  further.   The  following  can  then  be  shown: 

Theorem  5.6:   Let  (L,F)  be  a  1-related  distributive  data-flow 

framework.   Put  T^  =   T-„.      Then,  for  each  n  c  N*.  x"  =  y  . 

o    3K        .  '   n   -^n 

The  analysis  developed  in  this  section  and  the  previous  one  can 

be  modified  to  deal  with  non-distributive  data-flow  problems.   In 

the  non-distributive  case.  Theorems  4.6  and  5.2  only  guarantee 

inequalities  of  the  form  x'  <  y   (resp.  x"  <  v")  for  all  n  e  N*. 

n  —  -'n  '    ^   n  —  -'n' 

The  arguments  in  this  section  show  that  under  appropriate  conditions 
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y"  =  y   for  each  n  e  N*,  so  that  assiiming  these  conditions  Theorems 


n 


n 


5.4,  5.5,  5.6  all  yield  the  inequalities  x"  <_  y   for  each  n  c  N*. 
Thus,  in  the  non-distributive  case,  our  approach  leads  to  an  under- 
estimated solution,  as  is  the  case  for  intra-procedural  iterative 
algorithms  for  non-distributive  frameworks  (cf.  [KUl]). 
Example  5 :   We  return  to  Example  1  studied  in  Section  3.   Since 
available  expressions  analysis  uses  a  1-related  framework,  and 
since  the  flow  graph  appearing  in  that  example  satisfies  K  =  K'  =  2, 
we  can  take  r   =  Tg,  and  apply  Kildall's  iterative  algorithm  [KI] 
to  solve  Equations  (4.1).   The  following  table  summarizes  the  steps 


which  are  then  performed  (for  notational 
are  written  without  enclosing  parenthesis) : 

propagate  from   to 


call  strings 


updated  x*  value 


initially 
r. 


X*   =  {(X,0)} 

^1 

X*   =  {(A,l)} 

X*   =  {(C,,l)} 

^2      -^ 

X*   =  {(c,  ,0)} 

^2      ^ 

X*   =  {(Ct,1)} 


'2   ^2   ^r  ^  Uc^,l)  ,  (c^C2,0)  } 
J-   n-   x*   =  n*  (unchanged) 


n. 


X*   =   {(X,l)} 


n 


c*   =  {(c^,0)  ,  (c^C2,0)} 
f*   =  {(c^,l)  ,  (c^C2,0)  } 


n. 


n. 


X*   =  {(X,l)} 


c*^  =  Uc^,0)} 


workpile  of 
nodes  from 
which  further 

propagation  is 

required 

{r,> 

{c,} 

^-2> 

{C2} 

^^2'®2^ 

{e2,r2> 

{r2} 

{rj/Hj^} 

{n^/Cj} 

{n, ,C2 /e2} 

^<=2'®2'®1^ 

}  {e2,e^,r2} 

^®1'^2'^2^ 

{ej^,r2,n2} 

{r2/n2} 
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The  next  steps  of  the  algorithm  update  x*  ,x*  ,x*  ,x*    in  similar 

^2   ^2   ^2   ^2 
fashion,  adding  new  entries  with  increasingly  longer  call  strings, 

up  to  a  string  Cj^C2C2C2C2C2 ,  but  none  of  x*  ,x*  ,x*  or  x*   is  ever 

.■.■..  1   ^1   ^1    ^1 

modified.   Final  x*  values  for  the  blocks  appearing  in  our  example 

are 

""^2    "   ""^2    "    ^^^I'l)'     (CiC2,0),     (c^C2C2,0)     ...     (c^C2C2C2C2C2 , 0)  } 
^$2   "    ■^(^I'O)'     (^2.^^,0),    ...     (c^C2C2C2C2C2,0)} 

^n,   "    Uc^,0),     (c^C2,0),    ...     (c^C2C2C2C2,0)}       (^   x*    ,    by   the  way) 
z  C2 

An  x"  solution  can  now  be  easily  computed,  of  course,  this  is 
identical  to  the  solutions  obtained  by  previous  methods. 

Note  that  in  this  example  there  was  no  need  to  maintain  call 
strings  of  length  up  to  6  (length  2  would  have  sufficed) .  However, 
to  derive  correct  information  in  the  following  example  we  need  call 
strings  in  which  one  call  appears  three  times. 

Example  2 ; 


m. 


Sir  ^, 

/ 

call   p2  - 

1^-- 


return 


n. 


I   m. 
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The  shortest  path  showing  that  a*b  is  not  available  at  m'  is 

q  =  (r^^,  c^,  r^,    n' ,    c\    r^,  c^,  r^,    n^ ,  c^,    r^,    c^,  r^,    e^,   m^, 

®1'  "^2'  ^2'    ^1'    ®1'  "^')'  i"  which  c^  appears  three  times  before 
any  of  the  calls  in  q  is  completed. 

It  is  an  interesting  and  challenging  problem  to  find,  for 
a  given  flow  graph,  by  some  preliminary  analysis,  an  optimal  set 
r^  of  call  strings  needed  to  perform  some  particular  interprocedural 
data-flow  analysis  without  losing  information. 
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5.     An  approximative  call-string  approach 

In  this  section  we  present  a  modification  of  the  call-string 
approach  developed  in  Section  4,  which  yields  a  convergent  algorithm 
for  any  data-flow  analysis,  even  though  this  algorithm  may  in 
general  fail  to  produce  precisely  the  desired  (meet  over  all 
inter-procedurally-valid  paths)  solution.   However,  the  output  of 
the  algorithm  to  be  presented  will  always  be  an  underestimated  (and 
hence  safe)  solution.   This  compromise  which  is  useful  even  when 
L  is  finite,  can  make  the  call-string  approach  much  more  efficient. 
Moreover,  if  L  is  infinite,  F  is  not  bounded  or  does  not  admit 
compact  representation  then  this  modified  approach  is  one  of  the 
very  few  ways  to  perfrom  inter-procedural  analysis  that  we  know. 

Three  things  should  be  kept  in  mind  when  evaluating  any 
approximative  approach  to  an  interprocedural  data-flow  problem: 
(a)  Even  in  intraprocedural  analysis,  a  meet  over  all  paths  solution 
is  itself  an  underestimation  to  the  "true"  run-time  situation,  since 
many  of  the  static  execution  paths  which  enter  into  such  an  analysis 
may  not  be  executable.   (b)  Many  data-flow  analyses  whose  semi- 
lattice  L  is  not  finite  are  also  not  distributive  (cf.  [KUl]  and 
[SH])  so  that  even  the  intra-procedural  iterative  solution  of  the 
data-flow  equations  may  underestimate  the  meet  over  all  paths  solu- 
tion, and,  furthermore,  (c)  in  non-distributive  cases,  the  meet 
over  all  paths  solution  may  not  be  calculable  (cf.  [HE]  for  details). 

By  analyzing  the  abstract  approach  presented  in  Section  4,  we 
can  easily  see  that  the  convergence  (and  efficiency)  of  the  call 
strings  approach  depends  primarily  on  T.      Convergence  can  be  ensured 
in  general  only  if  r  is  finite,  and  the  smaller  r  is,  the  less 
complex  the  algorithm  becomes.   This  observation  motivates  the 
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approach  that  we  propose  in  this  section,  whose  general  outline  is 
as  follows. 

Choose  some  finite  (preferably  rather  small)  set  T   which  is 
closed  under  a  binary  operation  *  and  has  a  left  identity  with 
respect  to  this  operation.   (In  practice,  we  suggest  that  *  be 
associative  and  non-commutative,  but  the  general  description  given 
below  will  not  assume  this.)   As  in  Section  4,  let  T   denote  the  set 
of  all  call  strings.   Choose  an  "encoding"  map  a   which  maps  each 
call  block  to  some  element  of  r.   Using  *,  we  can  extend  a  to  r  by 
putting  a(Y)  =  a(c^)*a(c2)*  "•  *  ^(<=i^  (computed  left-to-right)  for 

each  Y  =  (c^,C2, ,c.)  c  P.   We  also  define  a (A)  to  be  w,  the  left- 

identity  of  T. 

Let  (L,F)  be  any  (not  necessarily  distributive)  data-flow 
framework.   We  will  define  a  modified  data-flow  framework  (L*,F*) 
in  essentially  the  same  way  as  we  did  in  Section  4,  but  with  some 
differences  reflecting  the  nature  of  the  approximative  approach,  as 

detailed  below. 

/\ 
p 
L*  is  defined  as  L  .   All  the  observations  made  in  Section  4 

concerning  L*  still  apply,  only  now  L*  is  bounded  since  T   has  been 

assiomed  to  be  finite. 

As  before,  in  order  to  define  F*,  we  first  define  an  updating 

operation  between  encoded  call  strings  and  edges  in  E*.   This 

updating  operation  is  now  more  complex  than  that  defined  earlier, 

and  in  order  to  describe  it  we  first  introduce  the  following 

Definition;   For  each  procedure  p  in  the  program  being  analyzed, 
define  ECS (p)  =  {a(CM(q)):  q  e  IVP(r^,r  )}.   This  is  the  set  of  all 
encoded  call  strings  which  result  from  interprocedurally  valid  paths 
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reaching  the  entry  of  p. 

These  sets  can  be  calculated  by  a  rather  simple  preliminary 
analysis  based  upon  the  following  set  of  equations  (where  main 
denotes  the  main  program,  which  is  assiimed  to  be  non-recursive)  : 

ECS  {main)    =    {w} 
(6.1) 

ECS (p)  =  {a*a(c) :  c  is  a  call  to  p  from  some  procedure  p'  and 

a  e  ECS(p')},  p  7^  main 

After  initializing  each  ECS(p)  to  0  ,    for  all  p  f^  main,    these   equa- 
tions can  be  solved  iteratively  in  a  fairly  standard  way.   (The 
iterative  solution  will  converge  because  T   is  finite.)   It  is  a 
simple  matter  to  prove  that  the  iterative  solution  yields  the  sets 
ECS(p)  defined  above. 

Using  the  sets  ECS  we  now  define  the  following  objects:  For 
each  n  c  N*,  a  set  of  inter-procedurally  acceptable  paths  leading 
from  the  main  entry  ton,  denoted  by  IAP(r,  ,n);  a  modified  set- 
valued  map  CM  from  L^   IAP(r, ,n)  to  2  ,  and  a  modified  set-valued 
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r 

operation  o:  F  x  E*  ->  2  .  These  recursive  definitions  are  as  follows 

(a)  The  null  execution  path  q   is  in  IAP(r,,r,)  and  CM(q  )  =  {w}. 

(b)  Let  n  e  N*  and  q  be  an  execution  path  leading  to  n.   Write 

q  =  qj^|l(m,n).   Then  q  c  IAP(rj^,n)  iff  q,  e  IAP(r,,m)  and  the  set 
A  =  u  {a  o(ra,n) :  a  e  CM(q^) }  is  not  empty,  where,  for  each 
a  £  CM[IAP(r^,m) ]  and  (m,n)  e  E*  we  define  a  o(m,n)  by 


a  o (m,n)=  ■ 


{a}   if  (m,n)  e  E° 

{a*a(m)}   if  (m,n)  is  a  call  edge 

{e  e  ECS(p) le*a(c)  =  a}   if  (m,n)  is  a  return  edge 

corresponding  to  a  call  edge  from  a  call  block 
c  in  procedure  p. 
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In  all  cases  we  define  CM(q)  to  be  the  set  A  introduced  just  above. 

The  intuitive  meaning  of  these  concepts  can  be  explained  as 
follows:  Since  we  have  decided  to  record  the  actual  call  string  by 
a  homomorphism  CM  of  paths  into  a  finite  set  T,    it  is  inevitable 
that  we  will  also  admit  paths  which  are  not  in  IVP (r   n) .   Thus 
IAP(r3_,n)  D  IVP(r^,n),  and  will  also  contain  paths  which  the  encoding 
CM  cannot  distinguish  from  valid  IVP  paths.   In  particular,  some 
returns  not  to  their  originating  calls  will  have  to  be  admitted. 
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An  inunediate  consequence  of  the  preceding  definition,  provable  by 
induction  on  the  length  of  the  execution  path  q,  is  as  follows: 

Lemma  6.1:   An  execution  path  q  is  interprocedurally  acceptable  iff 
CM(q)  7^  0. 

Having  defined  lAP,  CM,  and  o,  we  next  define  F*  in  essen- 
tially the  same  manner  as  in  Section  4.  Specifically,  for  each 
(m,n)^  c  E*  we  define  ff^^^j  :  L*  -  L*  as  follows:   For  each  C  c  L*, 
a  e  r 

%,n)^^)(<^)  =  ^^^{m,n)^^^''l^^'-    «  ^  ^i  o(m,n)} 
where  it  is  agreed  that  an  empty  meet  yields  «. 

F*  is  now  constructed  from  the  functions  f*    ,  exactlv  as 

(m,n)   ^'^•-v--'-^  aa 

before.   The  heuristic  significance  of  this  definition  is  the  same 
as  in  Section  4,  only  now  the  "tag"  updating  which  occurs  when 
propagation  takes  place  along  an   interprocedural  edge  involves 
less  extensive  and  precise  information.   The  modified  updating 
operation  that  has  just  been  defined  can  be  both  one-to-many  and 
many-to-one,  possibilities  which  are  both  reflected  in  the  above 
formula.   It  is  easy  to  verify  that  both  monotonicity  and  distribu- 
tivity  are  preserved  as  we  pass  from  (L,F)  to  (L*,F*) . 

Next  we  associate  with  (L*,F*)  the  data-flow  problem  of 
determining  the  maximal  fixed  point  solution  of  the  equations 

X*   =  {  (w,0)} 


(6.2) 

X*  = 

n 

(m,n)cE* 


"n  '    -   0...  'tm,n)  <-^'  '  ■>*«*-  '-!> 
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As  previously,  a  solution  of  these  equations  can  be  obtained  by 
standard  iterative  techniques.   Once  this  solution  has  been  obtained 
we  make  the  following  final  calculation: 

(6.3)  ^n  =  A  x*(a) 

"   aer 

The  techniques  of  Section  4  can  now  be  applied  to  analyze  the 
procedure  just  described.   Theorem  4.3  retains  its  validity,  if 
re-stated  as  follows: 

Theorem  6.2:   (a)  If  (L,F)  is  distributive  then,  for  each  n  c  N* , 
^n  "  K    -   AUj(x*  ):  p  c  path2^(r^,n)}. 

(b)   If  (L,F)  is  only  monotone  then,  for  each  n  c  N*,  x*    <_  y*    . 
Instead  of  Lemma  4.5,  the  following  variant  applies: 

Lemma  6.3:   Let  n  e  N*,  p  e  path^^ (r, ,n)  and  a  e  F.   Then 

f*(x*  ) (a)  is  defined  iff  a  c  CM(p) ,  in  which  case  f*(x*  ) (a)  =  fp(0). 

Proof:   By  induction  on  the  length  of  p.   The  assertion  is  obvious  if 
p  is  the  null  execution  path.   Suppose  that  it  is  true  for  all  paths 
with  length  <  k  and  let  p  =  (r.  ,s_ , .  . .  ,s,  ,n)  e  path  ^(r,,n)  be  a 
path  of  length  k.   Let  p,  =  (r, ,3- / . • . /S,  ) .   Then  for  each  a   c   T 
we  have 


Thus  fp(x*  ) (a)  is  defined  iff  there  exists  a,  e  F  such  that 

a  e  a,  o  (s,  ,n)  and  f*  (x*  )  (a,)  is  defined.   By  inductive  hypothesis, 
±  n  p,   r,    X 

this  is  true  iff  there  exists  a^^  c  CM(p,)  and  a  e  a.  o  (s,  ,n)  , 
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A 

and,  by  the  definition  of  o  and  CM,  this  last  assertion  is  true  iff 

a  e  CM(p) .   Hence,  applying  the  inductive  hypothesis  again, 

f*  (x*  )  (ci,  )  =  f   (0)  ,  for  all  a^  appearing  in  the  above  meet,  so 


that  this  meet  equals  f,     . [f   (0) ]  =  f  (0) . 

k'^   ^1        ^ 


Q.E.D, 


Remark ;   As  previously  noted,  and  can  be  seen,  e.g.  from  the  proof 
of  the  last  lemma,  use  of  an  encoding  scheme  creates  chances  for 
propagation  through  paths  which  are  not  interprocedurally  valid. 
However,  our  lemma  shows  that  even  if  an  execution  path  is  encoded 
by  more  than  one  element  of  Y ,    all  of  these  "tags"  are  associated 
with  the  same  information,  namely  -  f  (0) .   Thus  information  is 
propagated  correctly  along  each  path,  only  more  paths  are  now 
acceptable  for  that  propagation.   These  observations  will  be  made 
more  precise  in  what  follows. 

Lemma  6.4;   For  each  n  e  N*,  IVP(r^,n)  £  lAP(r^,n). 

Proof:   Let  q  e  IVP(r-,n)  for  some  n  e  N* .   We  will  show,  by  indue- 
tion  on  the  length  of  q,  that  a{CM(q))  e  CM(q) ,  so  that,  by  Lemma 
6.1,  q  e  lAP (r, ,n) . 

Our  assertion  is  obvious  if  q  is  the  null  execution  path. 
Suppose  it  is  true  for  all  paths  whose  length  is  less  than  some 
k  >_  0,  and  let  n  e  N*,  q  e  IVP(r,,n)  whose  length  is  k.   Write 
q  =  q^||(m,n).   By  inductive  hypothesis,  a(CM(q,))  g  CM(q, ) .   Now, 
three  cases  are  possible: 

o  y.  ^ 

(a)  (m,n)  e  E  .   In  this  case  CM(q)  =  CMCq^^)  and  CM(q)  =  CM(q^) 

so  that  a(Cl>l(q))  e  CM(q)  . 

(b)  {m,n)  is  a  call  edge.   Then, by  definition,  CM{q)  contains 
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0(CM{qj_)  )  *a(m)  =  a(CM(q)) 

(c)   (in,n)  is  a  return  edge.   Let  (c'/r  )  denote  the  corresponding 

call  edge.   Since  q  e  IVP(r, ,n),  q  can  be  decomposed  as 

q'  I  1  (c'/r  )  I  Iq"  1  I  (in,n)  ,  where  q'  cIVP(rj_,c')  and  q"  c  IVP^  (r  ,m)  . 

It  is  evident  from  the  definitions  of  the  quantities  involved  that 

that  CM(q)  =  CM(q')  and  that  CMCq^^)  =  CM{q ' )  |  [  (c '  )  .   Hence 

a(CM(q,))  =  a(cM(q) ) *a(c') .   It  thus  follows  that  a(CM(q))  is  a 

member  of  the  set  (3  e  ECS  (p)  |  B*a  (c* )  =  a(CM(qj^))}  which,  by 

definition,  is  a  subset  of  CM(q) . 

Q.E.D. 

We  can  now  state  an  analog  of  Theorem  4.6: 

Theorem  6.5:   (a)  If  (L,F)  is  a  distributive  data-flow  framework 
then,  for  each  n  e  N* 

Xj^  =  A  ^fp(O)  -    P  e  IAP(r3_,n)}  <  y^ 

(b)   If  (L,F)  is  only  monotone,  then,  for  each  n  e  N* 

^n  -  A  ^fp(O)  ''    P  ^  IAP(rj_,n)  }  <  y^ 

Proof:   (a)  Let  a  e  r.   By  Theorem  6.2  and  Lemmas  6.1  and  6.3,  we 
have 

x*(a)  =  /\{f^{x*    )  (a)  :  p  e  path^*  (rj^,n)  } 

=  Atfp(O):  P  c  IAP(rj_,n),  a  e  CM(p)  } 
Thus,  by  (6.3) 

^n  =  A^  x*(a)  =  A  {f  (0):  P  c  IAP(r,  ,n)} 
aer  ^  P  -L 

By  Lemma  6.4,  this  is 
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<  A  tf  (0)  :  p  c  IVP(r^,n)  }  =  y^ 


proving  (a) . 

(b)   Can  be  proved  in  a  manner  completely  analogous  to  the  proof  of 

(a),  using  part  (b)  of  Theorem  6.2. 

Q.E.D. 

Thus  (x  }  ,,^,    is  an  under-estimation  of  the  meet  over  all 
n  nci>I 

paths  solution  (y  }  ^jg*-   The  degree  of  under-estimation  depends  on 
the  deviation  of  IAP(r,,n)  from  IVP(r,,n),  and  this  deviation  is  in 
turn  determined  by  the  choice  of  F,  *  and  o.      The  most  extreme 
under-estimation  results  if  we  let  IAP(r,,n)  =  path  ^(r,,n)  for  all 
n  c  N*,  i.e.  define  T  =  (w),  w*w  =  w,  and  let  a  map  all  calls  to  w. 
If  we  do  this  then  the  resulting  problem  is  essentially  equivalent 
to  a  purely  intra-procedural-  analysis,  in  which  procedure  calls 
and  returns  are  interpreted  as  mere  branch  instructions. 

Another  more  interesting  encoding  scheme  is  as  follows.   Choose 
some  integer  k  >  1,  and  let  r  be  the  ring  of  residue  classes  modulo 

.'V 

k.   Let  ra  >  1  be  another  integer.   For  each  a,, a-  c    T,    define 
a,*a_  =  m-a,  +  a_ (mod  k) .   Let  a  be  any  map  which  maps  call  blocks 
to  values  between  0  and  m-1  (preferably  in  a  one-one  way) .   In  this 
scheme,  call  strings  are  mapped  into  a  base  m  representation  modulo 
k  of  some  encoding  of  their  call  blocks.   Note  that  if  k=<»  /  i.e. 
if  we  operate  with  integers  rather  than  in  modular  arithmetic,  then 
r  and  r  are  isomorphic,  with  *  corresponding  to  concatenation.   If 
k=m-' ,  for  some  j  ^  1/  and  a   is  one-one  and  does  not  map  any  call 
block  to  0,  then  the  encoding  scheme  just  proposed  can  roughly  be 
described  as  follows:  Keep  only  the  last  j  calls  within  each  call 
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string.   As  long  as  the  length  of  a  call  string  is  less  than  j, 
update  it  as  in  Section  4.   However,  if  q  is  a  call  string  of 
length  j,  then,  when  appending  to  it  a  call  edge,  discard  the  first 
component  of  q  and  add  the  new  call  block  to  its  end.   When  append- 
ing a  return  edge,  check  if  it  matches  the  last  call  in  q  and,  if 
it  does,  delete  this  call  from  q  and  add  to  its  start  all  possible 
call  blocks  which  call  the  procedure  containing  the  first  call  in  q. 
This  approximation  may  be  termed  a  call-string  suffix  approximation. 

At  present  we  do  not  have  available  a  comprehensive  theory  of 
the  proper  choice  of  an  encoding  scheme.   Appropriate  choice  of 
such  a  scheme  may  depend  on  the  program  being  analyzed,  and 
reflects  the  trade-off  between  tolerable  complexity  of  the  inter- 
procedural  analysis  and  some  desired  level  of  accuracy. 
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